Embedding & Integration

Session and Cookie corruption.

I hope this is the correct place to aske this. I'm working on a embedded page for Wordpress, and more info on my code is in that thread, but when I use the embeded user session info, and then visit my gallery2 installation, I have to clear my cookies.

Going through the embedded page allows me to Administrate from my embedded page, but destoys my sessions through the non embedded version.

Can gallery be embedded, and still accessable directly? Is there something I'm doing in my embedded page corrupting the sessions?

Thanks
John Arnold

Are there any planned changes to the embedded image block options?

So the External Image Block options allow

g2_blocks * Pipe(|) separate list chosen from randomImage, recentImage, viewedImage, randomAlbum, recentAlbum, viewedAlbum, dailyImage, weeklyImage, monthlyImage, dailyAlbum, weeklyAlbum, monthlyAlbum, specificItem
g2_show * Pipe(|) separated list chosen from title, date, views, owner, heading, fullSize; the value can also be none
g2_itemId Limit the item selection to the subtree of the gallery under the album with the given id; or the id of the item to display when used with specificItem block type
g2_maxSize Scale images to this maximum size
g2_linkTarget Add a link target (for example, to open links in a new browser window)
g2_itemFrame * Image frame to use around images
g2_albumFrame * Image frame to use around albums
( this is for the <?php @readfile('http//localhost/gallery2/main.php?g2_view=imageblockExternal&g2_blocks=randomImage&g2_show=title'); ?> found gallery2/main.php?g2_view=coreSiteAdmin&g2_subView=imageblockImageBlockSiteAdmin )

But the embedded image block options don't seem to limit. Adding an itemID without specificItem seems to error out.
The documentation doesn't mention g2_linkTarget, g2_itemFram, or g2_albumFrame.

Is it possible to use those other options with embedded image blocks?
Should itemId act as a limit when not used with specificItem while using the image block function in the embed class?

If I pass:

Array
(
    [itemId] => 23
    [blocks] => |randomImage
    [show] => title|date|views
)

I get:

Array
(
    [0] =& GalleryStatus Object
        (
            [_stack] => 
            [_errorCode] => 0
            [_fileName] => Array
                (
                    [0] => 
                )

            [_lineNumber] => Array
                (
                    [0] => 
                )

            [_errorMessage] => 
        )

    [1] =& 

)

If I pass

Array
(
    [itemId] => 23
    [blocks] => specificItem
    [show] => title|date|views
)

It works I get an image.
Also the External Image Block is prefaced with g2_ so to use g2_linkTarget, g2_itemFrame, or g2_albumFrame I just drop the "g2_"?

Set options to

Array
(
    [itemId] => 23
    [blocks] => randomImage
    [show] => title|date|views
)

Array
(
    [0] => GalleryStatus Object
        (
            [_stack] => 
            [_errorCode] => 0
            [_fileName] => Array
                (
                    [0] => 
                )

            [_lineNumber] => Array
                (
                    [0] => 
                )

            [_errorMessage] => 
        )

    [1] => 

)

and just an fyi the following works:

Array
(
    [itemId] =& 23
    [blocks] =& |specificItem
    [show] =& title|date|views
)

The only html I get with the first setting randomImage is [1] =>

now maybe its randomImage, let me try an album.

Ok I goofed. randomImage breaks if you select an image item, but if the item id is an album it works. I just need to document this in the WordPress Plugin code.

I don't think so. Wanna do it?

I am planning to work on integrating SMF with Gallery 2. I don't have anything set up yet, but I will get something set up soon.

Great to see you over here. Ive been waiting (as I cant do it myself) for a SMF/G2 integration. Hope to see some results in the next few months.

I would be interested in the progress of a geeklog integration and would also be willing to help... Very excited!!!

Imoq, find a developer with interest in integrating G2 in postnuke. Without such a person, the integration will slowly fade more and more obsolete.

Announcement:

Thanks to mindless' multisite+rewrite+embed change, everything should work now.

I tested an embedded (xaraya) multisite install, running the rewrite module and all java applets work, Gallery Remote too.*

The cookie fix (for those who lose sessions) will be in cvs in a week or so. We want some feedback on this change first before we commit the cookie change too.

*only if mode.embed.only is false in config.php

Announcement:

The rewrite module takes now embedPath as embeddedLocation when embedPath is set.
This is useful in a very rare use case: virtual hosts.
Say example.com/emApp/ and domain.com/ point to the same emApp/G2 installation.
Then, during the embedded g2 rewrite configuration, embeddedPath is set to /emApp/ if it was accessed with the first virtual host and to / if it was accessed with the later vHost.
With this change, you can use embedded G2 with virtual Host and the rewrite module activated.
You have to set embedPath in the GalleryEmbed::init() call dynamically. First detect if you are in vHost 1 or 2 (or ...) and then set the embedPath in the ::init call accordingly.

maybe the imageblock module was deactivated by the upgrade. go to site admin -> modules and make sure it's active.

yonie, i added the error message a few days ago. so if you're using the current nightly snapshot, you'd get an error when the imageblock is not active.

Announcement:

I recommend to all integration devs to either subsribe to this thread or to the devel mailinglist. I'll announce changes here and in the mailinglist in future.

We have to change the way we deal with cookies again. The current fix is uber-robust but it has a minor security flaw. It's open to session hijacking if you share your domain with other people.

The new fix is similar to what we had in beta 3. But in embedded G2, we append the GALLERYSID to all DownloadItem URLs. This is also not super secure, given that users like to copy'n'paste img urls to forums etc.
But you can define the cookie path in site admin -> general and then it won't append the GALLERYSID to downloaditem urls.

I'd recommend setting the cookie path during integration configuration time. When the integration gets installed, you could set the cookie path automatically with GalleryCoreApi::setPluginParam('module','core','cookie.path','/') (or a more secure/appropriate value).

The cookie change is not yet in cvs, but it will be in for beta 4.

Announcement:

Forgot about another change that will be in beta 4, also due to the cookie change:

GalleryEmbed::logout() now requires a param, similar to ::init.
Either embedPath or the current embedUri.

Sorry for that, but that's how it is. Security is more important than this param.

No, this does not affect GalleryEmbed::done().

It was required because with the new cookies, we set the path again dynamically.

Announcement:

The separate sidebar html is back! Kudos go to bharat for this one

But you have to change your integration code a little bit:
The new capability id is a little different:
To choose that the sidebar should not be displayed within the G2 bodyHtml, call this:
GalleryCapabilities::set('showSidebarBlocks', false);
To check if the sidebar html is available, check

$data = GalleryEmbed::handleRequest();
if (isset($data['sidebarBlocksHtml']) && !empty($data['sidebarBlocksHtml'])) {

$data['sidebarBlocksHtml'] is an array of blocks. This is an improvement over the old code if you want to do individual things with the blocks.
To just paste the whole sidebar somewhere, you could do this:

$html = '<div id="gsSidebar" class="gcBorder1">
' . join('', $data['sidebarBlocksHtml']) . '
</div>';

An alternative route we considered was having no sidebar capability at all. Each theme would either show a sidebar inside or not.
Then you could pick a g2 theme which doesn't show the sidebar in bodyHtml and render the sidebar blocks separately.
I guess in the long run, we will do something like this (e.g. you can administer the sidebar blocks in site admin -> theme, but they don't get rendered. You'd then call something like GalleryEmbed::getBlocks(array('sidebarBlocks')); after the handleRequest call.
But as I said, that's was an alternative which was not implemented right now. I'd still like to hear your opinions on this topic. You wouldn't have the feature to offer a "show sidebar inside" switch, but in the long run, themes that are tailored for your specific integration would be better, IMO.

Hi all. I just thought I'd jump and and mention that I'm looking at the Gallery 2 integration for Geeklog.

When I have something useful/usable, I'll post here.

- Andy Maloney

[http://imol.gotdns.com]

So, the relative path from the Server root (DocRoot)? As in /path/to/gallery, in the form of an array?
GalleryEmbed::logout(array('embedPath' => '/path/to/gallery'); (or is that path/to/gallery/ )
as opposed to the actual URI /path/to/gallery/index.php

Announcement:

Since Beta 4, there's an issue with embedded G2 and HTTP headers.
We start sending the headers in G2, thus if the emApp wants to send headers after the handleRequest call, you'll get a php warning.

This will be addressed shortly. Just wanted to confirm the issue.

Update: fixed in cvs / tomorrows nightly snapshot.

please visit nukedgallery.net for phpnuke / g2 issues.

asmaloney, G2 doesn't work with several emApps using it.
Things get complicated rather quickly. e.g. what about user synchronization? if emApp1 synchronizes its set of users to g2, g2 and emApp1 are in sync'. Now comes emApp2, also synchronizing users to G2. Suddenly, G2 has more users than emApp1 or emApp2, which is not a satisfying state. After all, we wanted to have the user tables of the different applications in sync.

You could argue that this is up to the user. If he wants to deal with the implications of such a state or if he guarantees that emApp1 and emApp2 already have the same user set, let him do so.

Also, a g_emAppId attribute for each row in the externalIdMap wouldn't be a bad idea in general. There already have been a few occasions where it would have been easier if there was such an attribute.

I guess we'll add it some time after g 2.0.

a nuke and a geeklog installation on the same server? pretty uncommon, since both of them serve about the same purpose.
do you sync the two or are the two installs completely independent? and do the users have to login twice, with different or the same username?

you'll end up with problems (user name collisions).
in g2, a username is unique.
the geeklog integration code could just choose username . rand() if there's a conflict and try again to create a g2 user, but that's not that nice.

and if there is a username collision, you don't know whether it is actually a new user or if it should be mapped to an existing user.

in the meantime, you can just add a prefix to all your externalIds.
when adding an externalIdMap entry from emApp1, tell g2 the externalId is 'emApp1_' . $realExternalId . that way, you accomplish the same as with a emAppId column.

but yes, I plan to add this emAppId column, but not right now.