On 03 May 2011, at 12:05, Michael Pavling wrote:
On 3 May 2011 10:54, Peter Hickman <[email protected]>
wrote:
Great way to annoy users "Thank you for providing correct
credentials,
but get lost anyway..." :-/
It would probably be nicer to deny on IP address first, that way you
wouldn't expose your login forms on systems whose IP addresses you
don't want logging in for whatever reason.
Here you are assuming that there is only one set of users / ip
addresses and that all users are being validated by ip address.
Well... I'm assuming the situation from one use case (given the very
limited info supplied to that point - "How to ... authenticate user
from login based on their IP address?")
Given the situation that there are multiple users accessing from
multiple ip addresses
It's always nice to get the info eked out in dribs and drabs... :-/
how do you propose to authenticate someone based
on their ip address if you don't know who they are?
Yup... given that situation, you don't have much choice (other than to
have different login forms for different user types - and that would
probably very quickly become the *worst* nightmare to manage)
Authentication is ENTIRELY edge cases :)
double-yup!
... which brings us back to the original question.
If you want to roll an authentication strategy that is not one of the
default (or additional) strategies available in Devise, you need to
write your own. Since your strategy is basically an "enhanced" (if you
can call it that way) version of database authenticatable, you can let
the code for that strategy inspire you to write your own.
There is no "hacking Devise" involved here. Devise has everything in
place to allow custom authentication strategies that you can either
pack in a gem or just add to your Rails project.
My colleague wrote a nice blog post about Devise strategies (albeit a
specific case): http://ewout.name/2010/04/http-basic-authentication-with-devise/
Once you get the hang of how Rack => Warden => Devise works, it's
quite easy to add that very complex and odd strategy that no one ever
thought of (prolly for good reason) to Devise. We have a few that
range from header-based API key authentication to "authenticator"-like
(short-term expiring passwords) authentication.
Also searching Google for "devise strategy rails" brings up quite a
few posts discussing the subject. And last but not least, you can
still look into the devise code itself (there's even quite a bit of
useful documentation in there).
Best regards
Peter De Berdt
--
You received this message because you are subscribed to the Google Groups "Ruby on
Rails: Talk" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
