Manage API authentication #4

Activity

1. jmettraux commented on Mar 11, 2017

   

   jmettraux

   on Mar 11, 2017

   Last edited by jmettraux

   Member

   More actions

   Hello,

   since flack is a Rack "app" (something that responds to call(env), for the app where I am using flor+flack I did it this way in the configu.ru:

   # (...)
   #
   # top Sinatra configuration then...
   
   require 'flack'
   require 'sg/flor_logger'
   
   class ManageFlowCheck
   
     def initialize(app); @app = app; end
   
     def call(env)
   
       s = env['rack.session']
       u = s && SilverGoose::Auth.user(s[:user_id]) rescue nil
         # fetch user from host application auth service
   
       if u && u.may?(:manage_flows)
         # the user has the right to manage flows, let her/him pass
         @app.call(env)
       elsif u
         # prevent access to valid user
         [ 403, {}, [ 'Forbidden' ] ]
       else
         # prevent access, not logged in, 404 would be better maybe
         [ 401, {}, [ 'Unauthorized' ] ]
       end
     end
   end
   
   map '/flack' do
   
     use ManageFlowCheck
   
     run Flack::App.new('flor/', start: false)
       # only start flor when auth credentials are available...
   end
   
   run Sinatra::Application

   My goal showing that is not to solve this issue, it's rather to remind us that Rack allows for deceptively simple solutions, those horses can let us ride far, provided we remember they're in the stable.
2. jmettraux commented on Mar 11, 2017

   

   jmettraux

   on Mar 11, 2017

   Last edited by jmettraux

   Member

   More actions

   authentication

   We should look at what's on the Rack market, maybe https://www.google.co.jp/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=ruby+rack+authentication+middleware&*

   authorization

   Maybe there is a Rack middleware out there to help us, but we should probably start with enumerating what can be done with flack:

   • POST a message to flack /message
     • a launch message
     • a cancel message
     • a tasker reply message
   • GET a list of executions /executions
   • GET a particular executions /executions/:exid

   For now that's all there is to it.

   Updated with point from #1
3. jmettraux commented on Mar 11, 2017

   

   jmettraux

   on Mar 11, 2017

   Member

   More actions

   @northox question, are we in sync if I say that you want to use flack(+flor) as a standalone service? Whereas I'm thinking of using it as some kind of admin nested in a flor-using application?

   I want to distinguish the two use cases, they can gain from each other, but we need to not confuse them.
4. northox commented on Mar 11, 2017

   

   northox

   on Mar 11, 2017

   MemberAuthor

   More actions

   Yes, exactly.

   Absolutely. The separation has to be VERY clear. That's what I was saying in #5:

   What I have in mind is to use Flack's API itself so it would be composed of two parts;

   1. to manage workflows (e.g. create,list) and;
   2. to act as a RESTful tasker - i.e. the Flack Tasker

   The first part being your admin nested in a flor-using application and the second being the standalone service.
5. northox commented on Mar 12, 2017

   

   northox

   on Mar 12, 2017

   Last edited by northox

   MemberAuthor

   More actions

   Your authentication implementation proposal seems to make sense but I think we should assign it to a far-away milestone or on-hold label as it's not a priority - at least for me. The whole point of have it here is for other users to do +1 if this is something they need.
6. jmettraux commented on Mar 12, 2017

   

   jmettraux

   on Mar 12, 2017

   Member

   More actions

   OK. let's welcome +1s and comments.
7. northox

   added

   enhancement

   on Mar 12, 2017
8. northox

   added this to the backlog +1 driven milestone on Mar 12, 2017