Function: CheckGalleryUserLogin
|
ozgreg
Joined: 2003-10-18
Posts: 1378 |
Posted: Mon, 2005-04-18 07:08
|
|
Greetings, The issue is if I turn off login's from the embedded G2 then should an (existing) gallery user cookie not exist for some reason I am not sure what options I have to handle this suitation. Option A) Silent login via an embedded GalleryAPI to restablish the Cookie using the External ID Suggestions??? |
|
Posts: 32509
I'm not sure if i understand the problem. Could you describe it step by step?
Note: even if G2 is embedded, it creates / manages its own cookies.
WP tells G2 with the GalleryEmbed::init(array('activeUserId' => $uid
that the user with the externalId $uid is authenticated. It then creates a cookie if no G2 exists for the user etc.
The only problem is that the G2 cookiepath for G2 standalone and G2 embedded may be different and that causes some problems when going back to standalone and people still have G2 embedded cookies.
So, what's your post about?
Posts: 1378
You just hit the nail on the head.. It is going back to standalone from embedded that is causing G2 to lose the cookie.. I was concerned that this would also happen when in embedded thus causing a suituation that the cookie would not exist and could not be created..
Glad someone has already thought down this path ;)
Posts: 32509
So is the question answered and no action has to be taken?
What I should solve sometime, but I'm not sure if it's possible at all:
When you have a G2 cookie from embedded mode and try to login in G2 standalone, the login just doesn't work. You have to manually delete the GALLERYSID cookie in your browser that corresponds to the G2 embedded mode session and then it works again.
Posts: 1378
Firstly question answered signed and sealed, no action required, your design is solid and well thought out ;)
Regarding the (embedded / standalone) cookie I do not have this issue, I found however it seems to happen when you execute the following..
require_once(dirname(__FILE__) . '/'.$gallerypath.'embed.php');
$ret = GalleryEmbed::logout();
Which and please correct me if I am wrong should only be executed when you are logging out of the calling application (ie Wordpress)
Posts: 32509
Right, this should only be called from WP when the user issues a logout command. The result should be that the user loses his sessions in both applications, i.e. he has a anonymous session in WP and G2 afterwards.
So you say if the user has logged out from WP (and this ::logout() is called too) and then tries to login in G2 standalone, he can't login and remains a guest user?
That's what I'd imagine, right. The G2 embedded cookie has usually path '/' and the G2 standalone cookie the path '/g2/' or something like that. I guess the cookie with the higher path has priority. But I'm not sure, I haven't looked into it.
Posts: 1378
Hmmmm good point, no easy way around this other than somehow controlling the settings of the path or setting up a different cookie for embedded applications??
Does Gallery have a function isgalleryuser()? because I need to execute something like this to check when WP executes a logout command to see if I should execute the logout command as well in Gallery..
Posts: 32509
Why? If the ::logout() method is called, it just resets the G2 embedded session. I.e. if the method is called for non G2 users, the user/browser will just receive a anonymous G2 embedded session. This isn't too bad, is it?
You could call: GalleryEmbed::isExternalIdMapped($wpUid); or something like that in GalleryEmbed, see embed.php quite at the end.
Posts: 1378
The logout is only part of the issue, you woulld also need something like this for sync'ing user data, even mass creating user accounts (when migrating DB's etc) although the option would be to just ignore all errors.
It is not big one, it would just be a slightly more tidy way of controlling the embedding process..
Posts: 32509
sorry, i still don't understand the connection between the ::logout function and updating user data or mass sync.
updating user data: if WP has a hook/event for an update user data event, then you could call there GalleryEmbed::updateUser().
if not, you need to synchronize users/user data periodically. and this is something i want to faciliate a little with a new GallerEmbedUserSync class, coming soon.
Posts: 1378
The assumption of your data model and please correct me if I am way off track is at all times Gallery and WP will be in Sync in terms of a user base.
Except that is not the case because I certainly do not want all users in my gallery, just a selected few, the rest are guests and will remain that way..
Thus without some way of knowing if a user is in gallery or not, any gallery function will just be executed blindly for all WP users (ie logout)
Get my drift?
Posts: 32509
but the logout() function doesn't harm the users that are not in G2. you can execute it for all users, if they are mapped or not.
and you are right with the model.
Posts: 1378
Agreed the Logout function is not a problem but what about say a update function. I can just see a requirement to only have a subset of users in the Gallery, thus it is going to make updates a little tricky..
For my 2c's some kind of API checking for a galleryuserexisting in the first place is not a bad idea.
PS: I should have titled this thread "101 and ways to examine the G2 DB model and how external syncing works"
Posts: 32509
In other threads about WP, I thought to have read that something like hooks exist in WP.
GalleryEmbed::updateUser($uid, $data)
Is there a update user hook/event in WP?
if so, then all you'd have to do there is:
- GalleryEmbed::isExternalIdMaped($uid)
- (and if so
same for a delete user event/hook in WP (just call ::deleteuser instead of updateuser).
I also think to remember to have read in one of the WP threads here, that someone wanted to create a WP patch for non-existant hooks and submit it to the WP devs. He thought, they would accept it.
I'd definitely prefer this way of synchronization. But if it's not possible for some reason (please explain), there will be some G2 functionality to sync WP with G2 periodically instead of keeping both apps in sync all the time.