Gallery Remote: Module incompatible with latest GR protocol
jonathan_hunt - January 2, 2008 - 10:03
| Project: | Image Publishing |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | egfrith |
| Status: | closed |
Description
I have tested with iPhotoToGallery 0.66 and Gallery Remote (java) 1.5. Neither would authenticate with Drupal via this module. It looks as if the Gallery Remote Protocol has been updated in several ways that break this module. Refer http://codex.gallery2.org/Gallery_Remote:Protocol
Specifically,
1. the callback to gallery_remote2.php should be main.php
- $items[] = array('path' => 'gallery_remote2.php',
+ $items[] = array('path' => 'main.php',2. All commands should be issued via POST and wrapped in an array (g2_form).
e.g. in _image_pub_gr_request()
+ $g2_form = $_POST['g2_form'];
+ if (isset($g2_form['cmd'])) {
+ $cmd = $g2_form['cmd'];
}and
- _image_pub_gr_login($_POST['uname'], $_POST['password']);
+ _image_pub_gr_login($g2_form['uname'], $g2_form['password']);etc.
3. There is an additional command, 'no-op'
+ case 'no-op':
+ _image_pub_gr_finish(GR_STAT_SUCCESS, '', 'No-op successful');
+ break;There are bound to be other things to be changed to match the new version of the protocol. This module might require refactoring to handle multiple different versions of the protocol.
#1
I have the same problem with Gallery Remote. Everything used to work fine, until recently. Now I get the message "Gallery Remote can find no protocol implementation at the URL ..."
#2
I've just taken over maintaining this module.
Thanks for the very helpful suggestions above. I will be taking a look at the whole module over the next few weeks.
Frankly I'm a bit puzzled about which version image_pub is supporting. It suggests in the code that it is supporting version 2.15, yet there is no reference to main.php.
The gallery remote protocol (version 2) is at
http://codex.gallery2.org/Gallery_Remote:Protocol
but I wonder if there is documentation about version 1 available somewhere so that if two versions are supported, we don't break support for version 1. Or perhaps this isn't necessary as very few applications use version 1 nowadays?
#3
Following the port to drupal 6, this bug is next on the menu.
I think it may affect whether the gallery remote client tries to communicate in UTF8 rather than HTML entities, which may have a bearing on #86440: Filenames do not get utf-8 encoded, so images fail to show and #204209: User authentification does not work under Gallery Remote.
Patches against drupal 6 would be welcome.
#4
Here is a first attempt at a patch for this bug. It basically does what is suggested in the original bug report, although it is possible to connect either via the version of the Gallery Remote 2 protocol implemented by Gallery Remote 1 (GR1 at gallery_remote2.php) or via the version of the protocol implemented by Gallery Remote 2 (GR2 at main.php).
There are some subtle differences between these two protocols, so the function _image_pub_gr_gallery_version() is introduced to return the gallery version number, based on whether $_POST[g2_form] exists or not. This affects the naming of albums [hence the changes to _image_pub_gr_get_albumid() and _image_pub_gr_get_albumname()]. Also the name of the element of the $_FILES array changes depending on the protocol, hence the extra argument to _image_pub_gr_add_image() .
I've also removed a reference to $_POST in _image_pub_image_add(), where it really doesn't belong. Now all of the reference to $_POST is in image_pub.gr.inc.
You'll need to apply the patch against the latest development snapshot. Also, you may have to "clear cached data" at admin/settings/performance.
I've tested this with Gallery Remote client 1.5 and f-spot 0.4.3.1.
#5
I should have mentioned; this patch is against the 6.x version of the module.
#6
Following some suggestions by bwynants, here is a new version of the patch that deals with the fact that $g2_form can be part of the $_GET array as well as the $_POST array.
I think it might also be worth trying to get the authToken part of the protocol working, as I suspect that some clients use this instead of session cookies.
@bwynants: It would be great if you could see if authToken is being used by your client. To test if your client pays any attention to it, you could replace the line in image_pub.gr.inc that says
"status_text=$message\n";with
"status_text=$message\n" ."auth_token=test_token\n";
Then looking at the PHP debugging output will show if a $_GET response with a g2_authToken is preset. If so, then it might be possible to fix authentication problems with clients that don't store cookies, though some thought would need to be given to how the "session" information is stored. Perhaps it might be possible to piggyback off the existing drupal session management.
#7
Given that there have been no negative reviews, I'm committing this patch now. The authToken stuff can be dealt with as a separate task.
#8
#9
Automatically closed -- issue fixed for 2 weeks with no activity.