At present, we don't handle basic authentication in the Warden middleware. We should.
Basic authentication strategy should be valid if params[:login] and params[:password] are present. (Possibly also supporting params[:email] in place of params[:login]).
Given these, it should authenticate the user and generate a new session. This should then form the basis of current_session.
Now, here's the thing... Middleware runs before controller actions on each request. It kinda makes endpoints like /login redundant... unless we can specify which strategies are allowed per Controller#action..?
Here you go: https://github.com/wardencommunity/warden/wiki/Strategies#using-strategies I've done this before but forgotten it: you can specify strategies in the authenticate method. So i could create different before_actions for different actions... and only allow :password/:basic on /login or only :refresh on /refresh.
Not only is this easy, it sounds cleaner too. Slight increase in code, but explicit strategy naming presents a cleaner view of what will actually be happening.
At present, we don't handle basic authentication in the Warden middleware. We should.
Basic authentication strategy should be valid if params[:login] and params[:password] are present. (Possibly also supporting params[:email] in place of params[:login]).
Given these, it should authenticate the user and generate a new session. This should then form the basis of current_session.
Now, here's the thing... Middleware runs before controller actions on each request. It kinda makes endpoints like
/login
redundant... unless we can specify which strategies are allowed per Controller#action..?Here you go: https://github.com/wardencommunity/warden/wiki/Strategies#using-strategies I've done this before but forgotten it: you can specify strategies in the authenticate method. So i could create different before_actions for different actions... and only allow :password/:basic on
/login
or only :refresh on/refresh
.Not only is this easy, it sounds cleaner too. Slight increase in code, but explicit strategy naming presents a cleaner view of what will actually be happening.