Important API Update - Security related changes

[devbobo]

G'day All,

As part of our recent security changes, the API has been upgraded for all versions.

To give developers a chance to upgrade their apps or frameworks, the new changes will be rolled out in 3 phases, the timings of the 3 phases are yet to be determined...

Phase 1: Active NOW !!
- Return AlbumKey and ImageKey information where required
- Handle errors for invalid AlbumKey/ImageKey if sent
- No other errors returned

Phase 2: TBD
- Return errors for Images or Albums (that were created after the new implemention of keys) if the ImageKey or AlbumKey parameters aren't sent or are invalid

Phase 3: TBD
- Return errors for all methods where ImageKey or AlbumKey aren't sent.

The changes, the following methods all now return either AlbumKey or ImageKey...

- smugmug.albums.get (AlbumKey)
- smugmug.users.getTree (AlbumKey)
- smugmug.albums.create (AlbumKey)
- smugmug.images.getInfo (AlbumKey)

- smugmug.images,get (ImageKey)
- smugmug.images.upload (ImageKey)
- smugmug.images.uploadFromURL (ImageKey)
- all other upload methods (ImageKey)

The following methods will require AlbumKey to be sent in addition to AlbumID...

- smugmug.albums.getInfo
- smugmug.images.get

The following methods will require ImageKey to be sent in addition to ImageID...

- smugmug.images.getInfo
- smugmug.images.getURLs
- smugmug.images.getEXIF

Additionally, anyone using the random image url will need to add AlbumKey as below...

http://nickname.smugmug.com/photos/random.mg?AlbumID=[AlbumID]&AlbumKey=[AlbumKey]&Size=Tiny

Documentation will be updated to reflect these new changes very soon.

Application compatibility list:

StarExplorer, version 1.0.0.186
SendToSmugMug, version 1.1.8056.0
Lightroom Export plugin, version 20080221.37
phpSmug, versions 1.0.6 / 1.1.4
AlbumFetcher, version 0.3.3
fotoflot.com, version 2.0.2.1000+
SmugSaver, version 1.4
SmugBrowser, version 0.5.5

If you have any questions or problems, please let me know.

Cheers,

David

[GarethLewin]

Sorry David, but I don't understand. Could you add to your post what albumkey and imagekey are?

[rainforest1155]

Gareth,

Have a look here for some details:
http://blogs.smugmug.com/don/2008/02...es-at-smugmug/

If that doesn't clear things up yet, see any of your SmugMug galleries - they all now have some attachments to the gallery ID and photo ID:
http://cmac.smugmug.com/gallery/2504...399_ZnZmK-A-LB

I hope this helps,
Sebastian

[devbobo]

bump

[David PL]

Originally Posted by devbobo

G'day All,

As part of our recent security changes, the API has been upgraded for all versions.

To give developers a chance to upgrade their apps or frameworks, the new changes will be rolled out in 3 phases, the timings of the 3 phases are yet to be determined...

Phase 1: Active NOW !!
- Return AlbumKey and ImageKey information where required
- Handle errors for invalid AlbumKey/ImageKey if sent
- No other errors returned

Phase 2: TBD
- Return errors for Images or Albums (that were created after the new implemention of keys) if the ImageKey or AlbumKey parameters aren't sent or are invalid

Phase 3: TBD
- Return errors for all methods where ImageKey or AlbumKey aren't sent.

The changes, the following methods all now return either AlbumKey or ImageKey...

- smugmug.albums.get (AlbumKey)
- smugmug.users.getTree (AlbumKey)
- smugmug.albums.create (AlbumKey)
- smugmug.images.getInfo (AlbumKey)

- smugmug.images,get (ImageKey)
- smugmug.images.upload (ImageKey)
- smugmug.images.uploadFromURL (ImageKey)
- all other upload methods (ImageKey)

The following methods will require AlbumKey to be sent in addition to AlbumID...

- smugmug.albums.getInfo
- smugmug.images.get

The following methods will require ImageKey to be sent in addition to ImageID...

- smugmug.images.getInfo
- smugmug.images.getURLs
- smugmug.images.getEXIF

Additionally, anyone using the random image url will need to add AlbumKey as below...

http://nickname.smugmug.com/photos/random.mg?AlbumID=[AlbumID]&AlbumKey=[AlbumKey]&Size=Tiny

Documentation will be updated to reflect these new changes very soon.

If you have any questions or problems, please let me know.

Cheers,

David

Hello,

Thanks for taking quick action on implementing this security change and incorporating it into the API.

I don't know how other developers have implemented their programs, but it seems it would be easier from a development standpoint to return the "id" and the "key" as a single "id" parameter (for example, "id=1234_abcd" instead of "id=1234&key=abcd"). Even if some developers have used the int type to store ids, it seems like the conversion to a string type would be less cumbersome to deal with then having to track and store 2 separate variables for each image/album.

This is just an observation and I'm sure other developers will have various input on how this impacts them.

Thanks again for all the work you do on the API.

[devbobo]

Originally Posted by David PL

Hello,

Thanks for taking quick action on implementing this security change and incorporating it into the API.

I don't know how other developers have implemented their programs, but it seems it would be easier from a development standpoint to return the "id" and the "key" as a single "id" parameter (for example, "id=1234_abcd" instead of "id=1234&key=abcd"). Even if some developers have used the int type to store ids, it seems like the conversion to a string type would be less cumbersome to deal with then having to track and store 2 separate variables for each image/album.

This is just an observation and I'm sure other developers will have various input on how this impacts them.

Thanks again for all the work you do on the API.

Hey David,

It may be more efficient that way (for a developer ), however it will potentially break a lot of existing apps, as the return type will no longer be an integer. Also, that would have resulted in me having to change nearly every single method to accomodate it.

Cheers,

David

[David PL]

Originally Posted by devbobo

Hey David,

It may be more efficient that way (for a developer ), however it will potentially break a lot of existing apps, as the return type will no longer be an integer. Also, that would have resulted in me having to change nearly every single method to accomodate it.

Cheers,

David

OK, I understand.

A couple of questions:

It looks like some of the API methods (such as smugmug.albums.delete) still only require the "id" parameter. However, is it always safe to include both the id and the key parameters even if the API method only requires the id parameter and not the key parameter? For example, is the API designed to simply ignore parameters that are not required for the particular method being called?

[devbobo]

Originally Posted by David PL

OK, I understand.

A couple of questions:

It looks like some of the API methods (such as smugmug.albums.delete) still only require the "id" parameter. However, is it always safe to include both the id and the key parameters even if the API method only requires the id parameter and not the key parameter? For example, is the API designed to simply ignore parameters that are not required for the particular method being called?

yes, that's correct

[GarethLewin]

Originally Posted by devbobo

yes, that's correct

Dave, I have been wondering about this change in general.

I understand you guys won't change, I am just wondering about alternate solutions, more to learn than anything.

You couldn't use a GUID because it would be too complex, but you could add a random 4 digit code.

Wouldn't just appending a new say 8 digit integer code at the end be just as good, and not require any new API?

If say the last image number before the change was 1234567890

then the next image would be 1234567891<random number> for example 12345678912546532

Wouldn't this be just as secure, but good enough?

I guess, people couldn't use integers, and that would break applications?

[Nikolai]

S*E 184 is now compliant with the new "keys" system. Both album and image keys are used thouthough the system.

[devbobo]

Originally Posted by Nikolai

S*E 184 is now compliant with the new "keys" system. Both album and image keys are used thouthough the system.

awesome... thanks Nik

[jerryr]

Hi - I am using this code presently to obtain the URL for an image(javascript):

urlToImage = webServer + "/gallery/" + AlbumID + "_" + AlbumKey + "/1/" + ImageID + "/Thumb";

How/where to I add the logic to obtain the ImageKey ????????

Thanks - jerryr

[Nikolai]

Originally Posted by jerryr

Hi - I am using this code presently to obtain the URL for an image(javascript):

urlToImage = webServer + "/gallery/" + AlbumID + "_" + AlbumKey + "/1/" + ImageID + "/Thumb";

How/where to I add the logic to obtain the ImageKey ????????

Thanks - jerryr

You need to either store it after the upload, or retrieve the image info later (you may need to get the list of images first if you don't know image id yet)

[jerryr]

Hi - I thought I would post this here - might be more appropriate...

function fixPhotoNav()
{
oPhotoNav = YD.getElementsByClassName("photoNav", "div");
for (i=0; i < oPhotoNav.length; i++)
{
re = /gallery\/([\d]+)(_(\w+))?\//;
oTitle = YD.getElementsByClassName("title", "span", oPhotoNav[i]);
if (re.test(window.location))
oTitle[0].innerHTML = "|&nbsp;" + oTitle[0].innerHTML + "&nbsp;|";
re.exec(window.location);
oPhotoNav[i].innerHTML = oPhotoNav[i].innerHTML + "<span ><a href=\"/gallery/" + RegExp.$1 + "\">return to album</a></span>";
}
}


Ok, here is what I discovered.
For previously created galleries, the modification above works fine.
For galleries recently created around the new security release, it takes you to the smugmug home page.
Check it out:
Created back in the Fall:
http://jrphotos.smugmug.com/gallery/3789668
No Issues - When you click on 'Return to Album' - takes you to the
albums thumbnails.
Created this past weekend:
http://jrphotos.smugmug.com/gallery/4311576
When you click on 'Return to Album' - takes you to the smugmug home page.
Any insight would be greatly appreciated - jerryr

[largelylivin]

May not be the right place.

This statement and others like it do not work. Any workaround or fix? Soon?

http://smile-123.smugmug.com/homepage/templatechange.mg?TemplateID=7&origin=http://smile-123.smugmug.com/keyword/finished

[devbobo]

Originally Posted by largelylivin

May not be the right place.

This statement and others like it do not work. Any workaround or fix? Soon?

http://smile-123.smugmug.com/homepage/templatechange.mg?TemplateID=7&origin=http://smile-123.smugmug.com/keyword/finished

please see this thread.

[brandofamily]

Originally Posted by jerryr

Hi - I thought I would post this here - might be more appropriate...

function fixPhotoNav()
{
oPhotoNav = YD.getElementsByClassName("photoNav", "div");
for (i=0; i < oPhotoNav.length; i++)
{
re = /gallery\/([\d]+)(_(\w+))?\//;
oTitle = YD.getElementsByClassName("title", "span", oPhotoNav[i]);
if (re.test(window.location))
oTitle[0].innerHTML = "|&nbsp;" + oTitle[0].innerHTML + "&nbsp;|";
re.exec(window.location);
oPhotoNav[i].innerHTML = oPhotoNav[i].innerHTML + "<span ><a href=\"/gallery/" + RegExp.$1 + "\">return to album</a></span>";
}
}


Ok, here is what I discovered.
For previously created galleries, the modification above works fine.
For galleries recently created around the new security release, it takes you to the smugmug home page.
Check it out:
Created back in the Fall:
http://jrphotos.smugmug.com/gallery/3789668
No Issues - When you click on 'Return to Album' - takes you to the
albums thumbnails.
Created this past weekend:
http://jrphotos.smugmug.com/gallery/4311576
When you click on 'Return to Album' - takes you to the smugmug home page.
Any insight would be greatly appreciated - jerryr

Hi jerry... I'm having the same issue... works for the old galleries and not the new ones... if you hover the "link" though, the url for the link shows as what we "wish it to be" but when you click you're taken to the SM homepage...
Seems to be a similar issue to that of the BZT hack... both work for old galleries, but not those created since the big change.... I hate change!!!

[voytek]

Originally Posted by devbobo

NOTE: we have temporarily suspended giving out api keys until all the security features have been rolled out, we'll post here when the suspension has been lifted.

If you have any questions or problems, please let me know.

Cheers,

David

Any idea when API key distribution will resume? I've got ideas bouncing around in my head, and would like to get them into code before I forget...

[Archeography]

I would also appreciate an ETA update for new API keys.

[Jshwaz]

I would really apprecaite an update as well. I have a developer waiting on this and its holding up production. Thanks!