Whatever I do I don't get the IP login to work. The link does not show on the login page (/user).

I see access callback is set to ip_login_is_possible and that function returns TRUE if $_SESSION[IP_UID_MATCH] > 0. So I tested for that session value, but it always returns 0. And when I look at IP_UID_MATCH, it contains string "ip_login_uid" which I believe should be a function... but there is no such function in the module..?!

Please help.

Comments

jim kirkpatrick’s picture

jim kirkpatrick commented

If if $_SESSION[IP_UID_MATCH] > 0 never equals TRUE, then there has not been a match in the database; No match found.

I'd start with the simplest case, make a user have just one IP, like 127.0.0.1 or the actual external IP if not developing locally, and make sure that user is logged in by IP. Make sure also that no other access code, modules or other features (like .htaccess) are involved.

And "IP_UID_MATCH" is a placeholder for "ip_login_uid" which is a string used in session variables, not a function...

vacilando’s picture

vacilando commented

I am trying it on a live site with one single external IP address as detected by whatismyip.com and also confirmed by showing ip_address(). But the link on the login page does not show. How can I better test what prevents it from showing?

jim kirkpatrick’s picture

jim kirkpatrick commented
Category: bug » support

Try running this code somewhere in a Drupal page:


// assuming [YOUR_IP] is 127.0.0.1 OR your external IP
print ip_login_check('[YOUR_IP');

The above should return the UID for the user with a matching IP address/range (though stick to single addresses for now). If you consistently get no response or 0 then a match is not happening because the IP has not been found in the database. Make sure there is a user with precisely that IP, no more no less.

The matching code hasn't changed for nearly a year, plus it works on my machine consistently, so I don't think this is a bug at this point in time...

jim kirkpatrick’s picture

jim kirkpatrick commented

You are using the field on the user edit page, not the obsolete profile field for 6.x-2.x, yes?

vacilando’s picture

vacilando commented

It returns "01"...?

I had used it with a profile field but today I cleanly uninstalled everything, deleted the field, and then installed the very latest 6.x-2.x-dev, set my own IP for the admin account, and I am trying to get it working...

jim kirkpatrick’s picture

jim kirkpatrick commented

"01" implies two calls, on returning 0 (no match) and one returning 1, or the admin user account... So something is being matched...

jim kirkpatrick’s picture

jim kirkpatrick commented

I'd also check the obvious stuff like browser caching and proxies etc... I'm sure you have but worth a gentle reminder!

vacilando’s picture

vacilando commented

I guess your code should've been: 

// assuming [YOUR_IP] is 127.0.0.1 OR your external IP
print ip_login_check(YOUR_IP);

It always returns "0" when I have the matching external IP in the admin account but also when I took it out of the admin and set it for another user account.

(To the gentle reminder -- thanks, but I always restart apache, memcached, varnish (running Pressflow), clear all Drupal and browser caches.)

jim kirkpatrick’s picture

jim kirkpatrick commented

Hmmm... strange. I'm out of ideas mate, sorry. It works for me across several tests...

The magic happens in ip_login_check(), so that's the place to start checking/debugging.

If you come up with anything - or need any other ideas - please do let me know.

vacilando’s picture

vacilando commented

Well, ip_login_check() always quickly returns at 

  if (!empty($_SESSION[IP_CHECKED])) {
    return $_SESSION[IP_UID_MATCH];
  }

$_SESSION[IP_CHECKED] cannot be populated because the part that sets it is below in the same function.
So it always returns $_SESSION[IP_UID_MATCH].

Now, $_SESSION[IP_UID_MATCH] is empty.

What about IP_UID_MATCH? It contains the string "ip_login_uid". It seems to me this is not correct; there should be a value here. That constant, is changed only a) after this condition in the same function (does not happen) and in b) the logout function (not relevant).

Ideas?

jim kirkpatrick’s picture

jim kirkpatrick commented

AHAH!!! The problem is that, to save database usage, the flag $_SESSION[IP_CHECKED] is set after checking to TRUE... so requests within that session will skip the check.

This explains your issue... The best thing to do is either open a new window in 'Incognito' or 'Inprivate' whatever mode - or another browser - so you have a completely fresh session, or delete the session cookies in something like Chrome or FireBug's editor.

Documentation needs updating, but there's an increasing need for a 'diagnostics' mode to help people in your situation.

As for the code, it's FINE! The $_SESSION[IP_UID_MATCH] actually gets converted to $_SESSION['ip_login_uid'] by PHP anyway, which represents that keyed value in the $_SESSION array - see the DEFINEs at the top of the module file. This is good practice - the avoidance of 'magic strings'.

Let me know how you get on with a 100% clean session.

vacilando’s picture

vacilando commented
Priority: Major » Normal

OK, Jim, thanks, this helped me to trace the culprit.

Up to now I was using IE for anonymous (IP login) testing. I cleared all caches in that browser, including cookies, but apparently the session was preserved somehow... damn IE!

So I went to Chrome, openend an incognito window, and quickly saw that there is a problem with another module.. http://drupal.org/project/legal
After disabling it, everything works OK.

The problem with Legal is somehow related to the fact that it does not allow access until the user accepts the current terms of the website. Somehow that check does not get displayed and IP Login fails. Do you think you could have a look into that within this issue or do we open a new issue for that?

jim kirkpatrick’s picture

jim kirkpatrick commented
Status: Active » Closed (works as designed)

These modules are incompatible because function legal_user() overrides the 'login' operation and will destroy the session to force people to agree to the T&Cs --- all the code is from line 254 of legal.module (6.x-8.x).

IP Login and Legal are likely incompatible because of session mashing, so you have 3 options:

  1. Try changing the module weights, making Legal 'lighter' or 'heavier' than IP Login (e.g. execute update system set weight = 10 where name = 'legal';, try with 10 and -10). Probably won't help though.
  2. Don't use Legal, use an alternative. Use another 'legal' type module: We use the Terms and Conditions module, only affects registration though, so that might not be what you want.
  3. Don't use IP Login... Not so many options here, IP Authenticator is abandoned...

Longer term the best approach is that various modules try to work together to deal with sessions better, and not step on each other's toes. However, this is a BIG thing and without a protocol to follow will likely not happen without architecture changes to Drupal core.

A similar problem exists with #1087822: IP Login incompatible with SecurePages Hijack Prevention module - not much IP Login can do about it at this point in time.

vacilando’s picture

vacilando commented
Category: support » task
Status: Closed (works as designed) » Active

Your explanation makes good sense. I don't even bother with #1 and #3 I know is not an option. So I'll use http://drupal.org/project/terms_of_use

Two things though:
a) Could you please list, on the project page of IP Login, which modules are known to be incompatible with it.
b) The module could detect that one of the incompatible modules is enabled and show a warning on the status page. This would really be ideal solution under the circumstances.
What do you think?

jim kirkpatrick’s picture

jim kirkpatrick commented
Category: task » support
Status: Active » Closed (fixed)

Moving to correct issue #1252990: Update documentation for 6.x-2.x and D7 branches

There's little chance we'll add the detection of incompatible modules - basically ANY module that destroys the session in certain operations will be incompatible -- that's way too much code burden on lots of moving targets. Better to just list them in the documentation as they crop up.