Devise - Authenticate based on IP

How to use devise to authenticate user from login based on their IP
address first?

On 3 May 2011 08:01, jack koh [email protected] wrote:

How to use devise to authenticate user from login based on their IP
address ?

?? How do you suggest that an IP address identifies a user?

Lend me your PC, and I’ll prove it’s a bad idea…

I want restrict only certain IPs can to access my App.
After authenticate IPs, username and password just allows user to
access.

On 3 May 2011 09:09, jack koh [email protected]lid wrote:

I want restrict only certain IPs can to access my App.
After authenticate IPs, username and password just allows user to
access.

That’s a very different problem then.

The easiest solution may be to use iptables (or similar) on the
server, failing that, put a before filter method into your application
controller that compares the request.remote_ip or request.remote_addr
to the list of allowed IPs you have. No need to hack into Devise.

However this assumes that the site is hosted in some place where the
firewall is easy to access. This is not always the case and even if it
is you really do not want the sysadmin or developer to be having to
drop everything just to make some small change to a firewall config
(and as any sysadmin will tell you, THERE IS NO SUCH THING AS A SMALL
CHANGE!)

It would be better if this were part of the app itself, it would mean
that it was portable and under the developers control - or even the
users control if the ip address was a user configurable option.

Could you not go for username / password access first and then reject
the user based on the ip address (a before filter that checks the ip
address and / or the x-forwarded header)? This would work the same way
but not require any hacking of Devise.

Do you have only one ip address (set) / user combination or are there
multiple users each of whom might come from different ip addresses.
Just as if you were allowing several institutions access to a service.

On 3 May 2011 09:53, Peter H. [email protected]
wrote:

However this assumes that the site is hosted in some place where the
firewall is easy to access.

What assumes this? Without you quoting anything, we’re into the realms
of having to guess what bit you’re replying to… and that way ends in
confusion…

I would like to point out that I said “the easiest solution may
be”… I’m fully aware that some parts of system config aren’t always
available - but it’s also worth considering that maybe if you can’t
access some part of the system that you want to, then maybe hosting
somewhere else maybe better… (again, “may”)

It would be better

Would it? I’d prefer to suggest options, and let the OP decide what
would and wouldn’t be best for them.

if this were part of the app itself,
(a before filter that checks the ip
address and / or the x-forwarded header)?

I suggested that too… did you stop reading my post when you objected
to the possibility of managing a firewall?

Could you not go for username / password access first and then reject
the user based on the ip address

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.

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.

Given the situation that there are multiple users accessing from
multiple ip addresses how do you propose to authenticate someone based
on their ip address if you don’t know who they are? Trust me on this,
this was exactly the situation that we had at the last company I
worked at, multiple institutions accessing from various sets of ip
addresses. We had to allow the user to enter their credentials before
we could check that they were actually allowed to access the service
from that ip address.

We even had to deal with people from one institution accessing the
service from a computer at another institution and some computers
(such as those found in libraries) being allowed access with a default
user from referrers or cookies set by the proxies. Also institutions
used their library card numbers to access the system (hardly a unique
identifier) which had to be backed up with other credentials behind
the scenes to allow the user smooth access to the correct resources.

We ran online reference sites that were accessed by Universities,
Colleges, Libraries and Companies all over the world. Site such as

http://www.oxfordreference.com/

http://www.oxfordartonline.com/

http://www.blackwellreference.com/

http://www.worldoflearning.com/

and many more. The company that I used to work for is called Semantico
(http://www.semantico.com/). The situations I have described, and many
more, are handled by the authentication system we built and it took a
lot of time to get the various edge cases to work as you would expect.

Again I say trust me, I spent seven years working on polishing the
authentication system used by Semantico and the sites that used it.

Authentication is ENTIRELY edge cases :slight_smile:

On 3 May 2011 10:54, Peter H. [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 :slight_smile:

double-yup!

On 03 May 2011, at 12:05, Michael P. wrote:

addresses and that all users are being validated by ip address.
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 :slight_smile:

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

Just a question… I am assuming the IP addresses will always be
static?

Thank for replying. Michael and Peter

Sorry, I’ve little confusing just now… due to rushing with my project.

Actually I would like to set certain user like admin which is can access
from outside [public IPs].

others users only can access within LAN.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs