API Update - 18th November 2010

devbobo

G'day Guys,

Tonight we shipped some new functionality for api version 1.2.2...
http://wiki.smugmug.net/display/API/API+1.2.2

Coupons
- Added album restrictions support for coupons.
- smugmug.coupons.create and smugmug.coupons.modify now appect an AlbumIDs parameter...a comma separated string of AlbumIDs to restrict the coupon to.
- also added smugmug.coupons.restrictions.albums.add and smugmug.coupons.restrictions.albums.remove to modify restrictions on an individual basis
- smugmug.coupons.get and smugmug.coupons.getInfo now return a Restrictions element if any restrictions exist.

BoutiquePackaging
- Added boutique packaging support to all album methods.

FeaturedAlbums
- Added smugmug.featured.albums.get

Cheers,

David

Kevin L. Kitchens

devbobo wrote: »

G'day Guys,

Tonight we shipped some new functionality for api version 1.2.2...

Coupons
- Added album restrictions support for coupons.
- smugmug.coupons.create and smugmug.coupons.modify now appect an AlbumIDs parameter...a comma separated string of AlbumIDs to restrict the coupon to.
- also added smugmug.coupons.restrictions.albums.add and smugmug.coupons.restrictions.albums.remove to modify restrictions on an individual basis
- smugmug.coupons.get and smugmug.coupons.getInfo now return a Restrictions element if any restrictions exist.

BoutiquePackaging
- Added boutique packaging support to all album methods.

FeaturedAlbums
- Added smugmug.featured.albums.get

Cheers,

David

Any changes to just logging in? I cannot connect via API.

Getting a System.Xml.XmlException: Root element is missing on login.

blackgold9

Well... my app is now reporting invalid api key... where it worked earlier. I'm not using oauth. That error actually failed my app in windows phone certification. Did anything change around keys?

devbobo wrote: »

G'day Guys,

Tonight we shipped some new functionality for api version 1.2.2...

Coupons
- Added album restrictions support for coupons.
- smugmug.coupons.create and smugmug.coupons.modify now appect an AlbumIDs parameter...a comma separated string of AlbumIDs to restrict the coupon to.
- also added smugmug.coupons.restrictions.albums.add and smugmug.coupons.restrictions.albums.remove to modify restrictions on an individual basis
- smugmug.coupons.get and smugmug.coupons.getInfo now return a Restrictions element if any restrictions exist.

BoutiquePackaging
- Added boutique packaging support to all album methods.

FeaturedAlbums
- Added smugmug.featured.albums.get

Cheers,

David

devbobo

Nothing changed from an API perspective with respect to logging in...but some work has been done on 'logging in' further down our stack. I've just double checked a few random apps that use basic auth...and they all seem to be working fine.

If your app is using an existing session, I suggest that you reset any SessionIDs or cookies that might be in use and obtain a new SessionID.

Cheers,

David

Kevin L. Kitchens

devbobo wrote: »

Nothing changed from an API perspective with respect to logging in...but some work has been done on 'logging in' further down our stack. I've just double checked a few random apps that use basic auth...and they all seem to be working fine.

If your app is using an existing session, I suggest that you reset any SessionIDs or cookies that might be in use and obtain a new SessionID.

Cheers,

David

Just tried again and getting "Root element is missing."

Code that's worked for many many months is now failing post-update.

snapwood

Thie login is broken for many of my users including myself...

JSON: {
"message": "invalid user",
"method": "smugmug.albums.get",
"stat": "fail",
"code": 4
}

This is with accounts that were working before the API upgrade.

Can we get this fixed?

Thanks,

Brian

snapwood

Technically, the log in is returning OK. It is the the albums.get call that is not liking the resulting session id that is generated from the login. There is no caching of old sessions in my app.

Login returns:

JSON: {
"Login": {
"User": {
"URL": "http:\/\/photos.snapwoodstudios.com",
"DisplayName": "radian09",
"id": 111111,
"NickName": "radian09"
},
"AccountStatus": "Active",
"PasswordHash": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"SmugVault": false,
"Session": {
"id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxx"
},
"FileSizeLimit": 25165824,
"AccountType": "Pro"
},
"method": "smugmug.login.withPassword",
"stat": "ok"
}

Get albums returns:

JSON: {
"message": "invalid user",
"method": "smugmug.albums.get",
"stat": "fail",
"code": 4
}

blackgold9

Thats what im seeing to

devbobo

As stated earlier, changes were made to our 'login' functionality lower in our stack than the api.

Developers who are experiencing issues are most likely not calling login methods over https. I'm working on a new release that will throw the correct error message.

Cheers,

David

snapwood

That is a bad assumption. Here are my urls with the responses. I am using HTTPS:

https://api.smugmug.com/services/api/json/1.2.2/?method=smugmug.login.withPassword&EmailAddress=myaddress%40gmail.com&Password=mypassword&APIKey=myapikey
JSON: {
"Login": {
"User": {
"URL": "http:\/\/photos.snapwoodstudios.com",
"DisplayName": "radian09",
"id": 567279,
"NickName": "radian09"
},
"AccountStatus": "Active",
"PasswordHash": "xxxxxxxxxxxxxxxxxxxxxxxx",
"SmugVault": false,
"Session": {
"id": "xxxxxxxxxxxxxxx"
},
"FileSizeLimit": 25165824,
"AccountType": "Pro"
},
"method": "smugmug.login.withPassword",
"stat": "ok"
}

https://api.smugmug.com/services/api/json/1.2.2/?method=smugmug.albums.get&Empty=true&Extras=ImageCount,LastUpdated,Public,Highlight,Description,Keywords,URL&SessionID=xxxxxxxxxxxxxxxxx
JSON: {
"message": "invalid user",
"method": "smugmug.albums.get",
"stat": "fail",
"code": 4
}

blackgold9

Same here. All my requests have the root url:
https://secure.smugmug.com/services/api/json/1.2.2/

quiks

devbobo wrote: »

As stated earlier, changes were made to our 'login' functionality lower in our stack than the api.

Developers who are experiencing issues are most likely not calling login methods over https. I'm working on a new release that will throw the correct error message.

Cheers,

David

That's it, right there! I was using HTTP Login in my iPhone app.... My iPhone app is now broken. I need to update to HTTPS and re-submit it.... it's gonna take a week until it's on the App Store again...
Is that by any chance possible to keep the HTTP login method enabled for another week or so, so that developers have time to re-submit their app to Apple ? Would be amazing!

Thanks,
Greg.

devbobo

snapwood wrote: »

That is a bad assumption. Here are my urls with the responses. I am using HTTPS

it might not be the cause of your issue, but I can guarantee that numerous apps are currently failing for that reason.

I'm currently investigating your problem, I need to reproduce internally before I can work out what is going on.

snapwood

Thank you! This is the second time in less than a month that 'changes' have broken mine (and other) apps. I would be happy to test these changes before rollout if there was a method. I'd be happy to submit tests (or point you to how to run our apps) if that would help. Basically I'll do anything to avoid breakages like this...

Thanks,

Brian

devbobo

quiks wrote: »

That's it, right there! I was using HTTP Login in my iPhone app.... My iPhone app is now broken. I need to update to HTTPS and re-submit it.... it's gonna take a week until it's on the App Store again...
Is that by any chance possible to keep the HTTP login method enabled for another week or so, so that developers have time to re-submit their app to Apple ? Would be amazing!

Thanks,
Greg.

Hey Greg,

I'd love to help out...but the recent changes were in relation to side jacking exploits. And I think I'd have a tough time getting the changes rolled back.

Sorry,

David

blackgold9

Thanks for being on it david.
I'm curious, what IS a side jacking exploit?

devbobo

blackgold9 wrote: »

Thanks for being on it david.
I'm curious, what IS a side jacking exploit?

just google side jacking or firesheep.

devbobo

Brian/Stephen,

I've reproduced the issue internally and have tracked down where the problem is...but I need to get more info on the recent underlying changes and that person is currently asleep.

One workaround is to only request login methods over https, and make all other calls over http.

Hope this helps a little bit.

Cheers,

David

devbobo

Heading to bed, just a recap for everyone...

- calls to smugmug.login.* need to be done over https
- all other calls should be done over http (temporary workaround)

Cheers,

David

Kevin L. Kitchens

devbobo wrote: »

Heading to bed, just a recap for everyone...

- calls to smugmug.login.* need to be done over https
- all other calls should be done over http (temporary workaround)

Cheers,

David

Just tried it again and it worked... Still using http

Andy

Kevin L. Kitchens wrote: »

Just tried it again and it worked... Still using http

That is temporary so that apps aren't busted right now... you will need to use https, more details will be forthcoming from Devbobo, thanks.

snapwood

Is there an ETA for fixing HTTPS urls not working? A workaround of an HTTPS login and HTTP API calls may be fine for a local test, but I can't deploy it out to hundreds of users and expect very fast penetration. Based on my emails, a lot of people are hitting this.

Thanks,

Brian

adamc

I'm seeing this also - very unhappy users of my Android app. I am using https for everything. Login is working, but albums.get is reporting invalid user.

devbobo

As part of overall site hardening against sidejacking, a new cookie _su is returned when logging in. This cookie is required to be present when making subsequent calls over https. Hopefully it's straight forward enough to enable cookie support for your apps.

Let me know if you have any questions.

Cheers,

David

adamc

Is this implemented yet? I see _ss, but not _su. Are we supposed to then set this in the header on every subsequent request?

devbobo

adamc wrote: »

Is this implemented yet? I see _ss, but not _su. Are we supposed to then set this in the header on every subsequent request?

Is this over anonymous session ? Only sessions created using smugmug.login.withPassword or smugmug.login.withHash will return the _su cookie...and only sessions created with those methods require it for subsequent https calls.

adamc

devbobo wrote: »

Is this over anonymous session ? Only sessions created using smugmug.login.withPassword or smugmug.login.withHash will return the _su cookie...and only sessions created with those methods require it for subsequent https calls.

This was a withHash login. I'll give it another try.

dappy

I'm almost a clueless noobie at this, but I did have an android app that was downloading and upload pictures. Until recently, that is. I happened to try it on the 19th and I got the same failure as snapwood. I'm also using https all around. I also see no _su cookie. I am also using loginWithHash. Interestingly, I'm using 1.2.1 API. Can anyone give me a clue what to do here, please?

Side note, I just remembered why I'm using 1.2.1: I have no idea how to make 1.2.2 work! My login attempt returns 17:

https://api.smugmug.com/services/api/json/1.2.2/?method=smugmug.login.withHash&APIKey=xxxxxxxxxxxxxxx&PasswordHash=xxxxxxxxxxxxxxxxxxxx&UserID=xxxxxxxxxx

If I change to 1.2.1, it works fine. (The login, anyway; everything else is broken as mentioned earlier.) So, question #2, I guess, is "What should my 1.2.2 loginwithhash url look like? Sorry if I'm hijacking this thread, I will move the discussion if need be.

Thanks,
Andrew

devbobo

adamc wrote: »

This was a withHash login. I'll give it another try.

Looks like there is an issue with the login.withHash method. I'll look into it today.

Cheers,

David

adamc

Thanks!

udy

devbobo wrote: »

Looks like there is an issue with the login.withHash method. I'll look into it today.

Cheers,

David

The _su is not sent in this case.