|PHP OAuth API||>||PHP OAuth API package blog||>||Painless OAuth with PHP||>||All threads||>||Double authorization request for Google||>||(Un) Subscribe thread alerts|
Marc-André Thiébaut - 2013-05-24 20:32:34
First, thanks for creating this package. I never needed to use OAuth before this week and basicly had little to no knowledge on the various APIs offered, but your exemples made it quick and basicly effortless to integrate OAuth for Google and Facebook logins.
Using database_oauth_client and mysqli_login_with_google (along with the other required files), I managed to make my login and database work exactly as desired except for one minor detai: Every time I login, I somehow manage to get 2 triggers of CreateOAuthSession (inserting 2 rows in my table, the last one gets updated with the access token) and 2 authorization requests from Google back to back (authorization request page loads a second time after I click the accept button. Facebook only asks once).
I'm 99.99% certain I did not change anything for the Initialize and Process functions, and I don't see Process being called twice anywhere. At this point, it's either working that way because it's supposed to, or my issue is somewhere else entirely.
I'd just like to know if this is the way it's supposed to go and stop looking for a bug there, or if it's an actual issue I need to fix.
Manuel Lemos - 2013-05-25 11:30:02 - In reply to message 1 from Marc-André Thiébaut
Could it be because one of the entries has an expired token?
The other only reason to create a session record again could be because the cookie that the class sets to keep track of the session was not really set. That may happen if you are testing the scripts in site without a TLD, like for instance localhost.
Marc-André Thiébaut - 2013-05-27 12:33:07 - In reply to message 2 from Manuel Lemos
Thanks for the quick reply,
It can't be caused by an expired token as it's literally the first entry (well 2 first as it double inserts right now) that are almost simultaneously created.
The cookie is set correctly on the 2nd entry. I just never get an answer on the first one.
But anyhow, I just wanted to confirm that the double entry was not something that is supposed to occur. I somehow manage to call the auth process twice somewhere in my code (probably load the same page or code twice >.<) but that's my screw up to correct!
Again, thanks for the great work on the package and thanks for the help! I'll most certainly use this again in future projects and strongly recommend it to my colleagues.
Manuel Lemos - 2013-05-28 08:05:37 - In reply to message 3 from Marc-André Thiébaut
There was a bug that may have caused that the first entry did not have set the user correctly and when it was being looked up with the correct user identifier it was not found, thus causing the creation of a second entry.
Anyway, the bug is fixed and the new version was just uploaded. Just let me know if this solved the problem.
Marc-André Thiébaut - 2013-05-29 13:59:56 - In reply to message 4 from Manuel Lemos
Sorry for the time it took to reply. I can't really test the changes as I've integrated a good bit of the code inside my user class itself: using MVC model with a colleague, had "standardize" the code to match the rest Was easy enough to move things around and keep everything working, so that's awesome.
In your examples, the same page is used to issue the call and receive the reply (or redirect) from the API and everything works perfectly.
In my case, the page that calls this is actually a "shortcut" (user/connectFacebook) to call a specific function (connectFacebook) from the controller (user). As this page is effectively invisible to the user, I didn't bother giving it a clean url, so to speak. However, my redirect_uri is profil/connexion-facebook (the website is in french). That url is actually equivalent to user/connectFacebook, and calls the same controller and function. Effectively, I could have just changed my url user/connectFacebook for profil/connexion-facebook and it wouldn't have been an issue, but I didn't "see it" until I actually understood the issue.
But, as far as cookies are concerned, unless the path is explicitly written, it is assumed the cookie is only accessible within the folder where it is set. In this case, the cookie was set in user/connectFacebook the first time and then again in profil/connexion-facebook when I got my answer back from Facebook, resulting in the first entry never actually being called back by the cookie as there was effectively no cookie to call it back from.
So, to resolve that, I only had to set the path as "/" (domain wide, 4th param of SetCookie() ) to allow my cookie to exist outside of it's default context.
Anyhow, that's something pretty basic, but because I had never really used cookies before, it completely stomped me. Took me far too long to figure out, but now that it's done, everything is working perfectly for me.
Again, thanks alot for the package and assistance :)
Manuel Lemos - 2013-06-05 12:00:23 - In reply to message 5 from Marc-André Thiébaut
I see. Now that you mentioned it, I just noticed that PHP sessions also set the cookie path to / by default.
I have just uploaded a changed version of the database class to also set / as default path for cookies. Just let me know if you still have problems.