Posted by PWG on August 12, 2009 at 9:18am
Jump to:
| Project: | Services |
| Version: | 6.x-2.0-beta1 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Hi,
I use Services and amfphp. When I log in via my flash app user.login it seems the session id is emptied in the anonymous session - but the session is still there - and then another, authenticated session is generated. Then, when I log out via user.logout, only the anonymous session with the empty sid remains.
Anyone have any idea why this could be?
PWG
Comments
#1
This should be resolved in 6-x-2-dev. 6-x-0.15 was only released to deal with a specific security issue and is basically superceeded by 6-x-2-dev.
#2
Great! Thanks, marcingy. So do you recommend me to switch to 6-x-2-dev? How stable would you say this version is?
Also, is there a list anywhere of the differences between 6.x-0.15 and 6-x-2-dev? The release notes do not say anything.
PWG
#3
#4
Phew! This was a tricky one.
I'm still in 6.x-0.15. Since it is stable enough for my needs I figured I might as well stay there until the dev version becomes the recommended version to use.
However, then I'm still stuck with the problem described above, and I'm hoping someone could give me a hint to solve it.
Recap:
It seems there is a problem in the login function that makes the logout function not work. Or there might be a problem both in the login funcion AND in the logout function. My real problem is not being able to log out. If I log in and log out immediately - the logout function does not seem to do anything at all. If, instead, I log in, end the flash program and restart and THEN log out, I get this error:
session_encode(): Cannot encode non-existent session.
I figured the logout problem might stem from the login function not behaving as it should. When I log in via Services with a Flash client, the anonymous session, it seems, is turned into this:
uid: 87
session id: [null]
timestamp: [e.g. 1254543399]
and then a new session is created as well:
uid: 87
session id: [e.g. svg3fsv3s5wik1co86jggur8n64]
timestamp: [e.g. 1254881397]
However, when I log in directly on the Drupal site, only thing that happens is that the anonymous session gets the correct uid and a new timestamp but keeps the same session id. In other words, no extra session record is added to the sessions table.
QUESTIONS: Is this how Services wants to behave? How do I fix this so that logging in via Services works as when logging in directly on the Drupal site? Is this problem connected to session_regenerate_id()?
Anyone has any idea? I'm tearing my hair over this.
#5
bump
#6
As the issue actually is fixed I'm closing this one.
#7
The problem is still there in beta1. I could use some fresh eyes on this - I'm almost out of hair to tear! :)
Some more information:
Forget #0 and #4 since they are somewhat dated.
The problem is the Login function. When a user logs in, the services_session_unload function creates TWO session records in the sessions table instead of just one. One of the session records looks fine and the other one has the correct uid BUT a BLANK sid.
How can I fix this?
#8
Anyone having this problem?
#9
I run several sites using session based services and have never seen this. I also just ran several tests and could not reproduce it. Sorry, not sure what to say but I have to mark this fixed until someone can show me something concrete.
#10
Automatically closed -- issue fixed for 2 weeks with no activity.
#11
Thanks, heyrocker. Although, my problem still remains of course. :(
Could this be related to amfphp maybe?
#12
Aaaaaah, just solved it! Quickly too. Took me less than a year. :)
I was digging to deep. Just for the protocol, the problem was that the session id variable I use in my actionscript was set correctly after system.connect BUT not after user.login - which resulted in an old non-existing session id being sent with the call to one of my custom Services functions after logging in. At which point a new session row with a blank session id was created by Drupal, causing trouble.
Still, should Drupal ever allow to be created sessions without session ids? Changed status to active just in case this is an issue.
#14
what trouble? in your case, services just treats your non-existing session as annoy session. There is a bug, and Services should reject the request if the sessionID is not in the database.
#15
#16
Automatically closed -- issue fixed for 2 weeks with no activity.