Upcoming API Changes - Please Read

gibertigiberti SmugMug SorcererPosts: 11Registered Users Big grins

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

APIv2 and OAuth are your friend! Having issues? Just ask, I can help!
Tagged:

Comments

  • Jeffrey FriedlJeffrey Friedl Beginner grinner Kyoto, JapanPosts: 14Registered Users Big grins

    Where is the documentation for 1.3?

    Do you have an ETA for when v2 will leave beta?

  • SidD726SidD726 IndiaPosts: 1Registered Users Beginner grinner
    Hello
    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
  • HZoneHZone Beginner grinner Posts: 3Registered Users Beginner grinner
    Hi Smugmug support,

    > @"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
  • havezethavezet Posts: 6Registered Users Big grins
    Hello all,

    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
  • havezethavezet Posts: 6Registered Users Big grins
    Sorry to bump this, but I need to get this resolved soon. Are there any suggestions?
  • Jeffrey FriedlJeffrey Friedl Beginner grinner Kyoto, JapanPosts: 14Registered Users Big grins

    @havezet said:
    Sorry to bump this, but I need to get this resolved soon. Are there any suggestions?

    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.....

  • havezethavezet Posts: 6Registered Users Big grins
    Hi Jeffrey, thank you for jumping in. The OAuth authorization/authentication flow is implemented working correct. I can make signed calls to the 1.3.0 API using OAuth signatures without issues. I can get albums, create albums using OAuth calls.

    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.
  • Jeffrey FriedlJeffrey Friedl Beginner grinner Kyoto, JapanPosts: 14Registered Users Big grins

    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.

  • havezethavezet Posts: 6Registered Users Big grins
    edited June 21, 2018
    Hi Jeffrey, I tried to summarize my steps;

    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
  • angsmugangsmug Posts: 1Registered Users, SmugMug Product Team SmugMug Employee
    > @havezet said:
    > 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
  • havezethavezet Posts: 6Registered Users Big grins
    edited June 21, 2018
    @ansmug; Thank you for your input. I'm developing this from scratch in FPC (FreePascal/Delphi).

    >> 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
  • Jeffrey FriedlJeffrey Friedl Beginner grinner Kyoto, JapanPosts: 14Registered Users Big grins
    edited June 21, 2018

    Since I'm not allowed to post links;

    The OAUTH_ENDPOINT is

    https api dot smugmug dot com slash services slash oauth

    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?

    in the entire authentication process you won't know who the user is.

    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 )-:

  • Jeffrey FriedlJeffrey Friedl Beginner grinner Kyoto, JapanPosts: 14Registered Users Big grins

    @havezet said:
    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

    For what it's worth, with the v2.0 API, the binary image data is indeed NOT part of the signature.

  • leftquarkleftquark SmugMug Product Team Posts: 3,149Administrators, Vanilla Admin, SmugMug Product Team SmugMug Employee

    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).

    SmugMug Director of Product / dGrin Afficionado
    aaron AT aaronmphotography DOT com
    Website: http://www.aaronmphotography.com
    My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
  • Jeffrey FriedlJeffrey Friedl Beginner grinner Kyoto, JapanPosts: 14Registered Users Big grins

    @leftquark said:
    We're here to support you and don't want to give the impression that we're not.

    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.

  • leftquarkleftquark SmugMug Product Team Posts: 3,149Administrators, Vanilla Admin, SmugMug Product Team SmugMug Employee
    edited June 23, 2018

    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?

    SmugMug Director of Product / dGrin Afficionado
    aaron AT aaronmphotography DOT com
    Website: http://www.aaronmphotography.com
    My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
  • leftquarkleftquark SmugMug Product Team Posts: 3,149Administrators, Vanilla Admin, SmugMug Product Team SmugMug Employee

    @Jeffrey Friedl said:
    Where is the documentation for 1.3?

    Do you have an ETA for when v2 will leave beta?

    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....

    SmugMug Director of Product / dGrin Afficionado
    aaron AT aaronmphotography DOT com
    Website: http://www.aaronmphotography.com
    My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
  • havezethavezet Posts: 6Registered Users Big grins

    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.

  • sarasphotossarasphotos Major grins Augsburg, GermanyPosts: 1,945Registered Users Major grins

    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!

  • DJDigitalDaveDJDigitalDave Big grins Berkeley, CAPosts: 81Registered Users Big grins

    @leftquark said:

    While we have the best of intentions for turning off older API endpoints, we certainly could have done better.

    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.

  • bwlbwl Beginner grinner Posts: 5Registered Users Beginner grinner
    @leftquark Thanks for coming in as a dim light at the end of the tunnel. Is it really not possible to reestablish the V1.2 endpoint until the issue is solved? This would enable us photographers to work. I hope you have all the stuff like version control systems, backups etc.

    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.
  • Jeffrey FriedlJeffrey Friedl Beginner grinner Kyoto, JapanPosts: 14Registered Users Big grins

    @leftquark said:
    I hope you’ve known the kind of company we strive to be and have been.

    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.

    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.

  • bwlbwl Beginner grinner Posts: 5Registered Users Beginner grinner
    > @"Jeffrey Friedl" said:
    > @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!
Sign In or Register to comment.