Hello,
Thank you for this very awesome, wonderful, life-easy-making module.
I have a little problem with ip_geoloc: when it's enabled, nobody can login. Something is wrong with $_SESSION, I don't know what exactly. The $_SESSION is reset upon login! login detail is lost and user is then redirected to the same page before without any message or warning.
However putting a `return` in the beginning of function `_ip_geoloc_set_session_value` fixes the problem. With or without session_cache, doesn't make a difference. Also this happens during login only. I tried to disable ip_geoloc_init() (so nothing is written to cache during login) but the same thing happens. any ideas?
Thanks again.
Comments
Comment #1
hkoosha commentedP.S: I tried both 7.x-1.25 and 7.x-1.x-dev they both have the same problem.
New update: Disabling ajax register fixes the problem. isn't there anyway to use them both?
Comment #2
rdeboerHi lootoo,
Thanks for your report and the feedback.
Not being able to login is not a little problem... it's a pretty big issue!
I had not heard of the Ajax Register module before. If I have time I may have a look at what's going on in terms of interference between the two modules.
For now let this just be a disclaimer that ip_geoloc cannot be used with http://drupal.org/project/ajax_register
Rik
Comment #3
hkoosha commentedThank you,
and if I found anything I'll post it.
Comment #4
hkoosha commented(un)fortunately the problem appeared again.
When ip_geoloc is enabled and it tries to write something to $_SESSION or session_cache (the module and it's api), it causes the invalidation of user session.
But to be more precise, the session is not invalidated, something is wrong with user's cookie which causes the mismatch between session on server and user's identity. Inspecting the watchdog, I can see user is successfully logged in, but there is no logged-out message.
Also, the user is redirected to his/her profile page. The theme function expects a valid user to show value of a name field from user's profile, say $name_of_user.
However because immediate session invalidation somewhere during bootstrap and page generation phase, before it gets to the preprocess function, the variable wont be set as there wont be a logged in user by then, and I get a php undefined variable $name_of_user warning.
And the final note: this strange behavior only happens during login. if a user is already logged in, everything works just fine (i.e: enabling ip_geoloc *after* logging in as admin or using the one-time password reset link).
I don't think there is an incompatibility with ajax_register there must be something else. strange isn't it?
any ideas?
thank you,
and best wishes
Comment #5
rdeboerHi lootoo,
This is strange and I understand what a pain this must be for you.
I guess one thing you could do is to avoid $_SESSION and cookie altogether by configuring Session Cache API to use the "FIle" option.
You could also visit the IPBV&M global configuration page and under "Data collection options" switch off all options. Then it should not use $_SESSION or Session Cache API
However, none of the above will address the root cause.
Given that ip_geoloc has over 3500 installs and this problem was never reported before, I believe that there must be some interference going on between IPGV&M and some other module, probably one that not many people use in combination with IPGV&M.
Rik
Comment #6
hkoosha commentedHi again, thanks for the kind response.
I configured sessions cache like this:
Where should user session data be stored?
- on the server, on core's cache database
Method for identifying the user in database and file-based storage methods
- via their login id, via cookie for anonymous users (works cross-browser for authenticated users)
It's working now!!! hooray!!
I can not turn off IPBV&M data collection options as I'm using them :D but I have a question: is 'on the server, on core's cache database' bad for performance?
Comment #7
rdeboerHi lootoo,
That's great!
I am both happy and puzzled, as I still don't understand what sort of interference IPGV&M/Session Cache API can possibly cause on your system.
'on the server, on core's cache database' is not bad for performance. The difference will be in the micro-seconds. You users won't notice which storage mechanism you have selected. They are all fast.
Rik
Comment #8
hkoosha commentedI wish I could send the list of enabled modules, I'm not allowed though.
I was thinking maybe I should port the part of the module which is locating visitors location, to it's own project? and IPGV&M can depend on that for this functionality?
And you can not possibly imagine how grateful I am for it when I look at the included js or the api.inc where coordination is calculated, I'd rather die than to write js :D
Comment #9
rdeboer:-)
Yes I prefer PHP over JS too. But that choice is often made for us, not up to us.
Comment #10
automan25 commentedI was having the same issue and lootoo's settings worked for me as well.
Comment #11
rdeboerThanks automan25 for sharing.
Still don't understand it though...
Comment #12
rdeboer