Upcoming API Changes - Please Read

gibertigiberti Registered Users Posts: 19 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:
«134

Comments

  • Jeffrey FriedlJeffrey Friedl Registered Users Posts: 32 Big grins

    Where is the documentation for 1.3?

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

  • SidD726SidD726 Registered Users Posts: 1 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 Registered Users Posts: 3 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 Registered Users Posts: 7 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 Registered Users Posts: 7 Big grins
    Sorry to bump this, but I need to get this resolved soon. Are there any suggestions?
  • Jeffrey FriedlJeffrey Friedl Registered Users Posts: 32 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 Registered Users Posts: 7 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 Registered Users Posts: 32 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 Registered Users Posts: 7 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 Registered Users, SmugMug Product Team Posts: 1 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 Registered Users Posts: 7 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 Registered Users Posts: 32 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 Registered Users Posts: 32 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 Registered Users, Retired Mod Posts: 3,784 Many Grins

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

    dGrin Afficionado
    Former SmugMug Product Team
    aaron AT aaronmphotography DOT com
    Website: http://www.aaronmphotography.com
    My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
  • Jeffrey FriedlJeffrey Friedl Registered Users Posts: 32 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 Registered Users, Retired Mod Posts: 3,784 Many Grins
    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?

    dGrin Afficionado
    Former SmugMug Product Team
    aaron AT aaronmphotography DOT com
    Website: http://www.aaronmphotography.com
    My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
  • leftquarkleftquark Registered Users, Retired Mod Posts: 3,784 Many Grins

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

    dGrin Afficionado
    Former SmugMug Product Team
    aaron AT aaronmphotography DOT com
    Website: http://www.aaronmphotography.com
    My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
  • havezethavezet Registered Users Posts: 7 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 Registered Users Posts: 3,822 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 Registered Users Posts: 84 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 Registered Users Posts: 11 Big grins
    @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 Registered Users Posts: 32 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 Registered Users Posts: 11 Big grins
    > @"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!
  • leftquarkleftquark Registered Users, Retired Mod Posts: 3,784 Many Grins

    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.

    dGrin Afficionado
    Former SmugMug Product Team
    aaron AT aaronmphotography DOT com
    Website: http://www.aaronmphotography.com
    My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
  • Jeffrey FriedlJeffrey Friedl Registered Users Posts: 32 Big grins

    @leftquark said:
    The goal here was for increased security across all SmugMug (enforcing secure requests eveeywhere) and i’m initially reluctant to go back.

    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.

  • soolishsoolish Registered Users Posts: 1 Beginner grinner
    edited June 24, 2018
    Actually, I can work around not having Jeffery's Plugin in the short term with export to disk and drag and drop. I need to reimport, reorganize and post items to my site immediately because I am going "live" to the Internet -- possibly with storefront features -- in the next two weeks. This is a hassle without his SmugMug tool but there is nothing for it. Nevertheless, going forward, it will be hard to live without its convenience and features which I have used for years. Whether you restore the old API or work with him to adapt to the new environment, I urge you to do it quickly. His knowledge and skill with Lightroom since the beginning has been an important source of supplemental information for my photography especially since I moved to the professional level. There is no one who understands the Lightroom internals like Jeffrey even at Adobe and there might not be a nicer guy on the Internet. Please do what you can soon.
  • leftquarkleftquark Registered Users, Retired Mod Posts: 3,784 Many Grins

    @Jeffrey Friedl said:
    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

    dGrin Afficionado
    Former SmugMug Product Team
    aaron AT aaronmphotography DOT com
    Website: http://www.aaronmphotography.com
    My SmugMug CSS Customizations website: http://www.aaronmphotography.com/Customizations
  • havezethavezet Registered Users Posts: 7 Big grins
    edited June 24, 2018

    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.

  • Jeffrey FriedlJeffrey Friedl Registered Users Posts: 32 Big grins

    @havezet said:
    Your concern about the user details is also less relevant.

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

  • bwlbwl Registered Users Posts: 11 Big grins
Sign In or Register to comment.