Re: exceptions while running the demo file photos.php - itbl...@gmail.com - com.googlegroups.google-picasa-data-api

10 messages in com.googlegroups.google-picasa-data-apiRe: exceptions while running the demo...

From	Sent On	Attachments
itbl...@gmail.com	22 Jan 2008 16:18
itbl...@gmail.com	22 Jan 2008 16:25
Ryan Boyd (Google)	22 Jan 2008 17:34
Ryan Boyd (Google)	23 Jan 2008 08:43
itbl...@gmail.com	23 Jan 2008 09:43
Jeff Fisher (Google)	23 Jan 2008 10:18
Jeff Fisher (Google)	23 Jan 2008 10:21
Ryan Boyd (Google)	23 Jan 2008 15:28
itbl...@gmail.com	24 Jan 2008 05:46
Ryan Boyd (Google)	24 Jan 2008 08:19

Subject:	Re: exceptions while running the demo file photos.php
From:	itbl...@gmail.com (itbl...@gmail.com)
Date:	01/23/2008 09:43:14 AM
List:	com.googlegroups.google-picasa-data-api

My mistake.

I have no excuses for falling in such a childish trap :-) Basic logic (I deleted the msg right after I posted it!).

Nevertheless It's not entirely because of me not thinking slightly longer than 2 seconds about boolean logic :-) What actually happened is that when I first executed the script I got an invite to log me in - which I did - but then couldn't manage access the main demo page! The script just kept redirecting me to the login invite page which for me couldn't mean anything else than "they finally got it wrong at google" :-( Now that I think about it, it probably was the script somehow not beeing able to set sessionToken (cookie problem?), that prevented the second boolean expression to even get evaluated. I am pretty positif about what I am saying because I even echo-ed the both expression's evalutions. By the way, what I finally did is exactly the same as what you describe (only I did it in one big authorize method):

function getAuthSubHttpClient() { global $_SESSION, $_GET;

unset($client);

if(!isset($_SESSION['sessionToken']) && !isset($_GET['token'])) { requestUserLogin('Please login to your Google Account.'); } else { if (!isset($_SESSION['sessionToken']) && isset($_GET['token'])) { $_SESSION['sessionToken'] =

Zend_Gdata_AuthSub::getAuthSubSessionToken($_GET['token']); } $client = Zend_Gdata_AuthSub::getHttpClient($_SESSION['sessionToken']); } return $client; }

Well, that's it.

I am going to test the new nightly download for addPhoto, but I am already having troubles once again with the "retrieveSelf" page. He doesn't seem to be able to retrieve data for "default". He's throwing a 404 error. For other user variables, it works.

Thanks

On Jan 23, 5:44 pm, "Ryan Boyd (Google)" <api....@google.com> wrote:

Hi,

On Jan 23, 2008 4:12 AM, itbl...@gmail.com <itbl...@gmail.com> wrote:

Ryan,

Thx for your answer :-)

//Clearly stops you evry time since the sessionToken is set in doSomething :-) if (!isset($_SESSION['sessionToken']) && !isset($_GET['token'])) { requestUserLogin('Please login to your Google Account.'); } else { doSomething(); }

This code does indeed redirect you to the login page in case you have no token AND the sessionToken isn't set; but just after the login process (you get the token, but no sessionToken yet -- in my version of the demo this variable is set in doSomething() ), you still can't access the page precisely because of the AND operator... They expect you to have both which obviously is impossible;

There are two conditions that must be met in order for the requestUser Login method to be called here: 1) The session variable named 'sessionToken' must not be set 2) The URL parameter named 'token' must not be set

In the case of the token being in the URL, but not in the session yet, this would result in: 1) The session variable named 'sessionToken' must not be set (TRUE) 2) The URL parameter named 'token' must not be set (FALSE)

TRUE && FALSE is equal to FALSE, so the 'else' part of the 'if' block is executed, and you aren't prompted to login.

If this is still a problem for you, I'd be interested in the proposed solution to see what differences are present (I'm still not seeing the logic problem in the above code, but perhaps I'm missing something-- also, the code works fine in my environment and that of a co-worker).

Thanks, -Ryan

This is just a detail anyway, so never mind (if somebody is interested I will post my solution to this when I get home and right after having tested the upload bug) :-)

The Firefox issue is repair, it was indeed a problem related to my env- cookies; sorry, false alarm;

On Jan 23, 2:35 am, "Ryan Boyd (Google)" <api....@google.com> wrote:

Hello,

Sorry about the problems you're experiencing.

The photo upload issue occurred for me too, prior to a fix that was submitted yesterday to the SVN trunk (seehttp://framework.zend.com/download/subversion/). That change is also available in the nightly download:

http://framework.zend.com/snapshots/ZendFramework-20080122-7558-en.ta...

More info on the problem with the photo upload is available on this thread (fw-gdata mailing list):

http://www.nabble.com/Gdata-Photo-Upload-Issue-to14222533s16154.html#...

This checks whether the session token is *not* set and the URL query parameter 'token' is *not* set. Reading over this code again, it looks correct. If neither of these attributes are set, it should prompt the user to click on the link and login to their Google account. The only reason it should hit this every time is if there's something not working right with the PHP session management and the sessionToken is never getting set in the session. This code runs fine for me.

Re the firefox issues with $_REQUEST['user'] -- this appears to be something specific to your environment. I believe that you have a cookie called 'user' in your firefox environment that is being sent to the server when making requests for the Photos.php. This is the danger of using $_REQUEST, as cookies appear to be populated last --- we probably shouldn't have used $_REQUEST in this case, but rather checked $_GET and $_POST individually when necessary, or always used one or the other. Try clearing this cookie or all cookies in FF and see if this resolves that problem.

The other issue you may run into with the Photos.php sample is with navigation using the back links. This needs fixed, but I haven't gotten to it yet.

Sorry about the problems -- but hopefully these things are resolved after taking a look at the items mentioned above. Please let me know how things work out for you.

Cheers, -Ryan

On Jan 22, 4:25 pm, "itbl...@gmail.com" <itbl...@gmail.com> wrote:

Some more details on the $_REQUEST['user'] bug;

With this url: http://localhost/Photos.php?command=retrieveAlbumFeed&user=name&album=... one is supposed to go to the retrieveAlbumFeed and the 'user' on the other side has got to be 'name'.

This doesn't work in Firefox 2.0.0.11; instead of user='name', I get user='JKDJJS444SASAJS__SAKSlk==' (or something pretty similar);

In IE and Safari this problem doesn't arise.

First when I started, nothing happened at all because this code here won't let you go anywhere near the web:

Then I had to struggle with my firefox browser which just didn't wont to load anything that has "...&user=name..." in it (meaning there is no way of going to the retrieveuser page; this -

http://localhost/Photos.php?command=retrieveSelf-forthename login

giveshttp://localhost/Photos.php?command=retrieveAlbumFeed&user=name&album...

but the user name gets grabled and a 404 error page is thrown). In IE6 and Safari this works just great :-)

Another problem... In none of these three browser did I manage to upload a picture; "Expected response code 200, got 415" or sometimes "root entry not found" (this one is pretty logic since no check is made whether the target album is empty or not) :-(

Deleting photos works only in Safari.

Now, could you please tell me whether the problem here is the demo php or is it gdata which is unstable?

Is there any robust example code out there or will I have to write it myself from scratch?