Skip to main content

Media Library Widget has stopped working

Robbie White

Hi, I had the Media Library Widget all set up and working in a design I'm working on, but somewhere over the last two days and (I think) without me having changed anything in the code on my end it has begun to fail to authenticate.

Nothing seems to work. Previously I was creating a timestamped sha hased signature on my backend and that was working smoothly.

Now I can't even login using the manual 'Please click here to log in using your username & password'

In the case of clicking on that link a new tab is opened, I log in but the original page with the medial library is not updated at all.

When trying to use the timestamped signature method I get a 401 error from 'rollbar.min.js:2' and an uncaught error in a promise the gist of which seems to be "Unsuccessful HTTP response"

Can you tell me is this is a known issue or something I am doing wrong?

1

Comments

15 comments

Date Votes
  • Stephen Doyle

    Hi Robbie,

    We pushed a change today to set SameSite=None on our login cookies; may I ask you to please try again?

    Regards,

    Stephen

    1
  • Robbie White
    Edited

    Hi Stephen.

    Yep that's the ticket. Setting the flags in chrome worked and now even with them turned off it's working fine. Excellent news and excellent work you guys, thank you :)

    I have noticed one other slight oddity that I've already found a work around for but may interest you guys.

    It appears that in safari the iFrame that renders the Media Widget Library blocks context clicks on elements even when the widget is not open. This isn't the case in any other browsers, but in my react app in safari onClicks work just fine but onContextMenu clicks are targeting the hidden/invisible media library iFrame.

    The obvious work around is to make the Widget inline and in my own dialog box, but it would be great not to have to worry about that extra step.

    Thanks again for fixing the cookie issue and for being so communicative while doing so :)

     

    Robbie

    1
  • NEC Prod

    Done. Thanks!

    1
  • Stephen Doyle

    Hi Robbie,
    Can you share the URL at which the widget is being used, either here or in a support request, so we can take a look?
    The rollbar error shouldn't be directly related to whether the widget is working correctly, but it may be another symptom of the same issue. 


    Are you able to see in your browser's debug tools where the source of the failure to log in is? Is your browser rejecting a cookie, for example, or failing to open one of the URLs on our side?

    If you can also please share which browser(s) you're testing in, that may help us determine where the issue may be

    Thanks,

    Stephen

    0
  • Robbie White

    Hi Stephen, thanks so much for getting back to me. Currently the project isn't live so it's all just running from localhost. ()

    I tested it in both Chrome (Version 78.0.3904.70 (Official Build) (64-bit)) and in Safari 13.0.2 and it fails in both (Tried with extensions off just in case... no dice)

    BUT I just tried it in Firefox and to my suprise and delight it works (With my original timestamped signature that used to work in all 3)! Which means it's a different issue than I had expected!

    in Safari I get the following 2 errors:

    • Failed to load resource: the server responded with a status of 401 ()
    • Unhandled Promise Rejection: [object Object]

    In Chrome similarly: 

      (anonymous) @ rollbar.min.js:2
      _._end @ client.js:772
      _.end @ client.js:676
      (anonymous @

    ApiClient.js:388
    the chrome unhandled rejected error gives me this stack:
     
     
    I'm now super confused as to why my code that was working in all three browsers hasn't changed but the Widget is only working in firefox! :)
    0
  • Stephen Doyle
    Edited

    Hi Robbie,

    This definitely sounds like something is interfering with the cookies used for authentication; another customer reported a similar issue which we're investigating now. 

    If it's the same problem, you may be able to work around this in Safari while we check and resolve the cause, by changing the "prevent cross site tracking" option in the settings and restarting Safari.

    For Chrome, we're continuing to check the cause; I'll keep you posted on the progress

    Regards,
    Stephen

    0
  • Robbie White

    Yep you're absolutely right, disabling prevent cross site tracking and restarting safari now allows it to work in safari as well.

    So I guess my chrome auto updated recently to a version with cookie controls that are conflicting with the way Cloudinary does this remote auth. Glad it isn't my end that's the issue, and wish you guys luck getting round this problem, can't wait to be able to get back to work! :)

    0
  • Stephen Doyle

    Hi Robbie,

    Thanks for confirming the scope of the issue; It's a little confusing because I also have Chrome 78.0.3904.70 and to my knowledge have not changed any cookie settings, but I'm not seeing the issue, so I'm not sure if there's some other factor at play, but we are investigating the cause now and I'll keep you updated when we make changes to address it.

    Regards,
    Stephen

    0
  • Robbie White

    Hi Stephen, any updates on this at all?

    Am I the only one seeing this error some how?

    I don't understand why I can't get it to work in 2 modern browsers and yet there seems to be no other mention of the problem anywhere. status.cloudinary shows the media library widget as operational even though it hasn't worked for me in the latest chrome for over a week now and I can't see any mention of the issue on twitter or anywhere else online.

    Any update at all would be appreciated as I will soon have to begin searching for a replacement product

    0
  • Stephen Doyle

    Hi Robbie,

    Interestingly, not many other customers have contacted us about this which makes me think it's not just the Chrome version used that's the issue, but also some combination of version, settings, existing cookies, etc. For example, I have the same Chrome version and all of our widgets load OK for me.

    That said, I understand it's causing you issues and we do have a fix prepared which is currently being tested - I'll let you know once I have more information about when that fix will be available in production - I should have more information later today

    Regards,
    Stephen

    0
  • Stephen Doyle

    Hi Robbie,

    The fix for this issue should be live in production this week and I'll let you know if that changes or when it goes live.

    In the meantime, you may be able to work around the issue by clearing cookies, making sure your browser's cookie settings are permissive, then logging back in via the widget

    Regards,

    Stephen

    0
  • Robbie White

    Hi Stephen, any update on this issue? Still not working for me in chrome, clearing cookies didn't work for me.

    0
  • Stephen Doyle

    Hi Robbie,

    The change I mentioned was merged to our master branch last week when I sent my last update, but during QA we found that not all cases are fixed by that change. While we continue to work on the issue, you may be able to update your Chrome settings so that it works for you.

    If you navigate to `chrome://flags/` and search for 'SameSite', the relevant settings are there: "Cookies without SameSite must be secure" and "SameSite by default cookies"

    Regards,

    Stephen

    0
  • NEC Prod
    Edited

    I've had no issues with Chrome or Firefox on desktop. However in Safari (mobile and desktop) I had to enable cross-site tracking as mentioned above. This doesn't seem ideal to me. Is there any plan to address that?

    The widget doesn’t work at all for me in Chrome for iOS. 

    0
  • Shirly Manor

    Hi Justin,

    Can you please open a ticket at support@cloudinary.com with the code that you are using for your widget for us to test it out?

    Thanks,

    0

Post is closed for comments.

Didn't find what you were looking for?

New post