User authentification does not work under Gallery Remote
pierrot@drupalfr.org - December 27, 2007 - 16:29
| Project: | Image Publishing |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | egfrith |
| Status: | closed |
Description
Hi
I've just intalled Image publishing that I use with Digikam
I've succeded to login into my site and the watchdog reports :
image_pub 27/12/2007 - 17:00 Session opened for <em>pierrot</em> pierrot
But when I try to add a picture or a gallery in the same Digikam export session, the watchdog reports :
image_pub 27/12/2007 - 17:00 Request failure: 401, The user does not ... Anonyme
with the message :
Request failure: 401, The user does not have permission to add an item to the gallery.
The authentification is not kept between the two opérations. When I allow anonymous users to put pictures on my site, Digikam can upload it.
Thanks to help me to fix this
#1
confirmed.
the same is happening here.
#2
I've looked into this problem. I think this is happening due to a change made between version 4.7 and version 5 of drupal core in the sess_write() function in sessions.inc. In 5, the session is not written to the sessions table if there is no cookie present. This is to prevent crawlers filling up the cookie table. Unfortunately, it also prevents user_authenticate() working in the context of this module.
What happens:
Request 1 of session: Web gallery client tries to authenicate by sending the 'login' request via HTTP post. user_authenticate() is called, and the user information is stored in $user. Drupal has *sent* a cookie to the client, but it is has not received the cookie as part of the request, so $_COOKIE is empty. Therefore at the end of the session, when sess_write() is called, no information is written to the sessions table.
Request 2 of sessions: Now web gallery client has a cookie, and sends it along with the request to "fetch-albums". However, because no data was wrtten to the sessions table on the first request, drupal thinks that it is an anonymous user (uid 0) that is asking for the data, and so refuses to allow any data out, unless the anonymous user is allowed to 'create images' and 'administer images'. On this request, the $_COOKIE variable is set, so the sessions table is written to - but with the uid as 0, not the intended uid.
I think the solution to this bug is a minor change to the sess_write() function. I will post that as a separate issue in the core queue.
#3
As promised, there is a patch at #293612: user_authenticate() should work when $_COOKIE is empty.
#4
The patch at #293612: user_authenticate() should work when $_COOKIE is empty looks as though it probably will get into drupal 6 and 7, and may be backported to 5. Probably best to leave this issue open until the patch is applied though.
#5
same problem here gallery remote does not seem to work anymore due to this.....
patch does not help?
#6
The patch at the bug I mentioned above doesn't apply to the drupal 5 tree -- perhaps that was the problem you had with it? I'm attaching a patch that should work with drupal 5. Please let me know if it fixes the problem, and I can add the information to the README file.
#7
nope, it does not help for my problem. I had applied this patch manually....
#8
Hmm... I think we need to debug the problem from the ground up. First of all, does your patched drupal tree allow you to login to drupal when cookies are not set? To test this (see http://drupal.org/node/293612#comment-960809):
0. Make sure you are logged out of your drupal site
1. going to yourdrupalsite.tld/user
2. clear your cookies
3. enter your username and password and click login
Does the login succeed or fail?
#9
it succeeds (using a mac with safari or ff)
it succeesd with or without the patch....
( I also have http://drupal.org/node/40545 applied to session.inc)
#10
Hmmm... I'm a bit mystified, as the bug #293612: user_authenticate() should work when $_COOKIE is empty has been reproduced by others in HEAD and by me in clean drupal 6.x and 5.x trees. The 6.x tree contains the patch you mention.
However, this suggests that you are at least able to authenticate without cookies. I suppose the next step is to try and debug what drupal thinks is going on with whether the user is authenticated. I used watchdog statements in various functions in image_pub.module to print out which user had made the request. I haven't got the lines I used here, but I might still have them on another machine -- I'll look later.
#11
I did some source level debugging. I will try it again. I'm familiar with php, less with sessions and cookies...
BTW I have a test server available with my code. email me for an account if you want to verify the login?
#12
#13
I think that the patch at #205535: Gallery Remote: Module incompatible with latest GR protocol, comment 4 *may* fix the problem underlying this bug.
#14
As I think the bug underlying the original problem has been fixed, I am going to close this bug. However, I am aware from email correspondence with bwynants that there still may be a problem with some clients, in particular later versions of ApertureToGallery.
@bwynants: if you'd like to pursue the problem, please feel free to open a new issue referring to the clients that are giving problems.
#15
Automatically closed -- issue fixed for 2 weeks with no activity.