Upcoming API Changes - Please Read
giberti
Registered Users, Vanilla Admin Posts: 19 SmugMug Employee
Hello Developers,
There are some important changes coming that may affect you. Please read carefully.
Requiring TLS (https):
Effective June 11th, 2018, SmugMug will begin requiring all API traffic to be secured using standard TLS 1.1 (or greater) encryption. For most platforms, this should be as simple as switching your API endpoints from http://api.smugmug.com/ to https://api.smugmug.com/ but may require additional work if you are using out of date software.
Upgrading API version:
In an effort to ensure we continue to provide the best possible experience for developers, we are going to be disabling two of our older legacy API versions. Developers looking to leverage the most current features SmugMug offers will need to consider moving to our APIv2 platform. An easier path for some developers will be to migrate to API 1.3, which has a very similar syntax to the older API versions.
The timeline for turning off the old API versions is:
- API 1.1: May 21st, 2018
- API 1.2: June 11th, 2018
Erik
SmugMug Sorcerer
Comments
Where is the documentation for 1.3?
Do you have an ETA for when v2 will leave beta?
How to I get SessionId using api.
As I have gone through the api documentation but there is no api request url to get SessionId. Please let me know asap.
Thank you
> @"Jeffrey Friedl" said:
> Where is the documentation for 1.3?
>
> Do you have an ETA for when v2 will leave beta?
Jeffrey is the author of a popular plugin to allow publishing from Lightroom to Smugmug, jf smugmugg. Photographers such as myself relly on this plugin due to its flexible and poweful processing of keywords and other Metadata. The withdawal of older API versions has broken this plugin for all users, significantly reducing the overall value of Smugmug as a platform for many users. Please can I urge you to provide Jeffrey with as much support as possible to transition to an updated/supported version of the API. I would also urge you to temporarily reinstate the older versions to provide a more reasonable amount of time for developers to transition. It must have been possible to tell from your sever logs that common plugins such as this where still using the old API versions and to provide targeted warnings both to developers and users of your intention to withdaw support?
Regards Ian Hardy
hzone.smugmug.com
I'm in the process of moving from API 1.2.2 to 1.3.0. The switch to OAuth went smooth and all standard API methods works fine, including signing of the query strings.
But...I can not get the upload to work. I'm using a POST to https upload dot smugmug dot com URL (sorry, but I can't post links here) but I keep getting error 35=Authorization failed. I've tried about everything but without more details why my AUthorization header is disapproved I'm somewhat in the dark and so would appreciate some extra eyes looking at it.
The headers I'm sending is (changed values for X-Smug-AlbumID, oauth_consumer_key, and oauth_token):
Headers:
Content-Type: image/jpeg
Content-Length: 158254
Content-MD5: f61f8b1b968936b5693e41291590bdc3
X-Smug-AlbumID: 99999999
X-Smug-Title: My Title
X-Smug-Caption: My Caption
X-Smug-FileName: 040124-Canon EOS 10D-IMG_1805(001).jpg
X-Smug-Keywords: Tag
X-Smug-Hidden: false
X-Smug-ResponseType: REST
X-Smug-Version: 1.3.0
Authorization: OAuth oauth_consumer_key="my key",oauth_nonce="1D703FBF257B4243AC9D3080011640FA",oauth_signature_method="HMAC-SHA1",oauth_timestamp="1529150836428",oauth_token="token",oauth_version="1.0",oauth_signature="owx6H9eszOe9E2QBsdFyshl97Ko%3D"
This is the string that was signed;
POST&https%3A%2F%2Fupload.smugmug.com%2F&oauth_consumer_key%3Dmy key%26oauth_nonce%3D1D703FBF257B4243AC9D3080011640FA%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1529150836428%26oauth_token%3Dtoken%26oauth_version%3D1.0
What am I overlooking here? Any clues why the server disapproves my upload requests with error code 35?
Thank you
I'd help you debug the upload issue if I could get that far. What do you use for the various OAuth endpoints? The documentation at https://api.smugmug.com/services/api/?version=1.3.0 seems to be both incomplete and incorrect.....
It's only the POST call to https upload dot smugmug dot com that isn't working. It keeps returning ErrorCode 35 - Authorization failed. The Authorization header with OAuth is in place as shown in my opening post. The signature is calculated identical as used in the other API calls.
I must be signing either the wrong URL, a slash somewhere at the end? Do I need to include the header fields in the signature? Right now all that is included in the signature is the OAuth elements. This is the string that was signed:
POST&https%3A%2F%2Fupload.smugmug.com%2F&oauth_consumer_key%3Dmy key%26oauth_nonce%3D1D703FBF257B4243AC9D3080011640FA%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1529150836428%26oauth_token%3Dtoken%26oauth_version%3D1.0
My signature must be different from what the server expects me to sign. Unfortunately this is all poorly documented.
Sorry havezet, I was asking exactly how you authenticate the user via OAuth.... what is the v1.3 version of https://api.smugmug.com/api/v2/doc/tutorial/authorization.html ?
I can authenticate using the "Request Token URL", "User authorization URL", and "Access Token URL" seen in https://api.smugmug.com/api/v2/doc/tutorial/authorization.html, but I get no information about the logged in user (their name, nickname, etc.), which prevents me from moving far enough along where I can even attempt an image upload.
Once I can get far enough to try uploading an image, I can try to debug the signature issue, but I'm just not there yet and SmugMug themselves are not answering at all, so I'm hoping that you can tell me.
Since I'm not allowed to post links;
The OAUTH_ENDPOINT is
https api dot smugmug dot com slash services slash oauth
1. Request temporary token:
GET OAUTH_ENDPOINT/getRequestToken.mg?Callback=...
Pass the oauth query parameters, but not a oauth_token, as you don't have it yet. Do also sign the request
Returns the temporary oauth_token and oauth_secret;
e.g.oauth_token=12345&oauth_secret=98765
2. Authorize access:
BROWSER OAUTH_ENDPOINT/authorize.mg?oauth_token=12345&Access=Full&Permissions=Modify
This is when the user needs to authorize access in the web browser for the smugmug website. Pass on the temporary token from step 1
After success, the token verifier is sent to the provided calback URL in step 1
3. Pick up the token verifier as received in step 2
In SmugMug's case the verifier is a dummy. You won't need it...this could be a design flaw though minor
4. Exchange the temporary token for the permanent token
GET OAUTH_ENDPOINT/getAccessToken.mg
Make sure to pass on the oauth query parameters, together with the oauth_signature using the temporary token
Returns the permanent oauth_token and oauth_secret;
e.g.oauth_token=54321&oauth_secret=56789
The user is now authenticated.
The reference that I used was: https smugmug dot atlassian dot net/wiki/spaces/API/pages/689052/OAuth
This description is very basic and hardly useable
PS; in the entire authentication process you won't know who the user is. In your application you could ask the user for their nickname before starting the authentication process. Then after authentication you can then lookup the user details with the API method smugmug.users.getInfo. I haven't done that as I don't need the user details in my app
> But...I can not get the upload to work. I'm using a POST to https upload dot smugmug dot com URL (sorry, but I can't post links here) but I keep getting error 35=Authorization failed. I've tried about everything but without more details why my AUthorization header is disapproved I'm somewhat in the dark and so would appreciate some extra eyes looking at it.
>
> The headers I'm sending is (changed values for X-Smug-AlbumID, oauth_consumer_key, and oauth_token):
> Headers:
>
> Content-Type: image/jpeg
> Content-Length: 158254
> Content-MD5: f61f8b1b968936b5693e41291590bdc3
> X-Smug-AlbumID: 99999999
> X-Smug-Title: My Title
> X-Smug-Caption: My Caption
> X-Smug-FileName: 040124-Canon EOS 10D-IMG_1805(001).jpg
> X-Smug-Keywords: Tag
> X-Smug-Hidden: false
> X-Smug-ResponseType: REST
> X-Smug-Version: 1.3.0
> Authorization: OAuth oauth_consumer_key="my key",oauth_nonce="1D703FBF257B4243AC9D3080011640FA",oauth_signature_method="HMAC-SHA1",oauth_timestamp="1529150836428",oauth_token="token",oauth_version="1.0",oauth_signature="owx6H9eszOe9E2QBsdFyshl97Ko%3D"
>
>
> This is the string that was signed;
> POST&https%3A%2F%2Fupload.smugmug.com%2F&oauth_consumer_key%3Dmy key%26oauth_nonce%3D1D703FBF257B4243AC9D3080011640FA%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1529150836428%26oauth_token%3Dtoken%26oauth_version%3D1.0
>
> What am I overlooking here? Any clues why the server disapproves my upload requests with error code 35?
>
> Thank you
Hi
Can you check to ensure that your POST request body on the upload request is also being included as part of your request parameters being signed?
Also, can you tell me what language you're using to construct your upload request? Are you using an open source OAuth library to assist you in constructing the request?
Thanks
>> Can you check to ensure that your POST request body on the upload request is also being included as part of your request parameters being signed?
The body of the POST contains the image binary data (not encoded, just the binary stream of the file). Should that also be included in the signature?
The OAuth specification explicitly states that only form-encoded data should be included and so it doesn't appear that the binary image data should be included in the signature
That must have been a lot of work to type... thank you so much. I'm sorry you had to go through it... why can't you post links?
What? Is there no way to find out who the user is? That would be ridiculous..... (but perhaps par for the course, for a company that decommissioned the only production servers available to developers )-:
For what it's worth, with the v2.0 API, the binary image data is indeed NOT part of the signature.
I'm hopping onto this thread so I can monitor it for replies. I'll make sure that we have an engineer or two available to answer any questions that come up. We're here to support you and don't want to give the impression that we're not.
(These threads are causing some continued discussions internally here around the API and we've got some thoughts in the works to better support all of you. Stay tuned).
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
Considering that there's no answer nor even reply to the first two posts in this thread, no answers nor even reply to messages sent to api@smugmug.com, and no answer nor even reply to various other threads in this forum, you've already cemented a very strong impression.
I've worked with SmugMug as a developer for over a decade, and in the old days, communication between SmugMug and developers was quick, fluid, and mutually beneficial. What happened to you?
My app for Adobe Lightroom, which has hummed along and supported your customers for more than a decade, broke because you turned off the only production servers you had, after a minuscule 30-day notice at a forum that you don't normally even participate in (so how could you expect longtime developers to have ever noticed)? Your logs certainly told you exactly which developers and customers would be impacted, yet you still turned them off without real notice, knowing it would leave those affected customers in the lurch. One can only imagine this was a considered decision, and from this one can only conclude that you simply do not care about those customers. THAT is the impression you're giving; if you want to give some other impression, you need to go about things a lot differently.
Jeffrey,
You’re not wrong. I hope you’ve known the kind of company we strive to be and have been. The poor communication you’ve outlined is not what we want to be. We’re not afraid to admit when we’ve made a mistake and this is one of those times. I’ve hopped onto this thread as a step towards improving that communication. Our COO, several engineers, our Director of Ops, and countless others have been brainstorming today on how we can avoid the lapses that have occurred. While we have the best of intentions for turning off older API endpoints, we certainly could have done better. Kaydin, one of our Account Managers had been in close contact with our top API consumers but we obviously missed reaching out to you. We’re working on some changes so that doesn’t happen again.
As a few first steps, I’m on this thread and check dgrin constantly and can act as a liaison between you, other developers and our engineers. Several members of the team have been added to the api@smugmug email address and @angsmug, one of our senior backend developers will be helping out here on dgrin. There’s further discussions going on regarding moving api2 out of beta.
Is there anything you’re waiting on us that I can make sure we get back to you ASAP?
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
I'm working on tracking this down. Discussions on bringing v2 out of beta are currently being held (for example, we've been using it internally for many years). Responses coming shortly....
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
Thank you for participating leftquark.
Just now I've sent precise details of my upload request, reply and signature to the email address. I hope this allows the developers to debug this and understand what I do wrong or why the server denies the upload requests.
As one of the customers affected by this, I am happy to hear that there may be some progress on this front. I've been using Jeffrey's plugin happily for years and really don't want to change my workflow. It would be nice to be able to start uploading again soon!
Sure would be great if you could temporarily turn back on the production servers until Jeffrey has a chance to get his app up and running on the new api. I'm sure I'm not your only customer whose workflow has been totally disrupted by this situation.
www.djdigitaldave.net
If you follow semantic versioning a change in the minor version should backwards compatible, while perhaps adding more features. Therefore I would expect 1.2 clients also be able to work with 1.3 (maybe only need to change the endpoint).
I understand the motivation to use Oauth, But In my opinion this should be done in a major version. I am working with the Dropbox API which changed recently to V2. They were sending emails to any developer (they know them through registering for an API key) over the last year. They requested a confirmation that the information was accepted. They raised frequent warnings to the developers sill using V1 in the last four weeks before turning off V1. And They supported V1 and V2 for one year in parallel.
Having 2.0 API (which as major version might break backwards compatibility) on beta for four years does not give much trust :-(
Long story short: After an accident like this, please take temporary countermeasures to make us work again. - Means: temporarily providing 1.2 endpoints.
http://blog.weichel21.de
http://bwl.smugmug.com
It's because I know what you used to be, and what you strive to be, that I'm so taken aback by what has happened. Had Big Faceless Company done it, I'd have just chalked it up as par for the course. You're a family company that acts like a family, so recent events have been a surprise.
The underlying user data model for 2.0 seems to be completely different from 1.x (in the latter I tie user history to their numeric user id, but that numeric user id seems to not be available in 2.x). I've sent email to api@smugmug.com asking about how to convert this and other ids.
Turning 1.2 back on temporarily would be nice to get your customers that use my plugin back on their feet, while I work to move to the beta API.
And just to be clear about my motivations, I'm not asking for this for myself. I give my plugin away for free, so it doesn't matter to me directly whether your customers are supported or not supported. I care about supporting Adobe Lightroom and its users, and that demographic nicely meshes with SmugMug's, so I'd always felt we were on the same team.
> @leftquark said:
> Is there anything you’re waiting on us that I can make sure we get back to you ASAP?
>
> Turning 1.2 back on temporarily would be nice to get your customers that use my plugin back on their feet, while I work to move to the beta API.
>
> And just to be clear about my motivations, I'm not asking for this for myself. I give my plugin away for free, so it doesn't matter to me directly whether your customers are supported or not supported. I care about supporting Adobe Lightroom and its users, and that demographic nicely meshes with SmugMug's, so I'd always felt we were on the same team.
Jfriedls Plugin kept me working with Smugmug for the last 10 Years! I have published 13000 Photos with this plugin. I have a shooting today and do not know how to publish the results. So bringing back 1.2 would not only be nice - no it is a strong request!
http://blog.weichel21.de
http://bwl.smugmug.com
I’m currently looking into how many customers are impacted before we consider re-enabling the older API. The goal here was for increased security across all SmugMug (enforcing secure requests eveeywhere) and i’m initially reluctant to go back. Once I can get a quick handle on the number of customers impacted I’ll have a better assessment.
I’ve reached out to a few engineers to make sure we respond to the api emails.
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
I totally understand the desire to move away from smugmug.login.withPassword; I should be able to move over to the beta API quickly if I can get answers to questions.
So it wouldn't need to be for long... a few weeks at worst, I imagine.
FWIW, I'd already used only HTTPS endpoints, so no need (on my plugin's behalf) to turn on HTTP servers.
Great to know. I’ll talk it over with the team. They’re also telling me they’ve got a few people responding to the emails so let me know if you don’t get responses
Former SmugMug Product Team
aaron AT aaronmphotography DOT com
Website: http://www.aaronmphotography.com
My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
I got the uploads to work. The support developer pointed out what I did wrong and the error was so basic and stupid that I can't believe I overlooked it while looking at all the detailed logs that I record (and eventually sent to the SmugMug dev). I must have been oblivious. Simply put: I forgot to set a property for my upload class with the shared secret and so the signature was missing part of the key. For other class instances I did set the property and so that's why the rest of the calls were working, Thanks SmugMug, for the extra pair of eyes to look at the details and help resolve this.
@Jeffrey Friedl, apart from the OAuth signing the API 1.3 is working identical as 1.2.2 and so once you get the OAuth implemented, the rest of your code should still work (unless, like me you forget to assign a property haha). Your concern about the user details is also less relevant. As I mentioned in an earlier post, you could ask the user for their nickname and then lookup the details of the user. In 1.2.2 you probably ask for a username/password. Then with 1.3 you'd ask for their nickname before starting the OAuth process.
I'd be more than happy to help you get this implemented soon, so I'll keep an eye on this thread.
Asking for their nickname before starting is ridiculously kludgy, but I'd do that if that's all I need, but I also need their SmugMug numeric user ID, which is something the user would have no clue about.
Thank you, though, for your kind offer to help. I still have hope that SmugMug itself will eventually rise to do the same....
It seems that https://api.smugmug.com/services/api/?version=1.3.0&method=smugmug.auth.checkAccessToken also retiuns the user id among others.
http://blog.weichel21.de
http://bwl.smugmug.com