End users can't sign in with Safari

56 コメント

  • Brett - Community Manager
    コメントアクション Permalink

    Hey German,

    Any chance you have a screenshot of the error you're receiving? I may need to create a ticket on your behalf so any additional information you can provide will help our Customer Advocacy team troubleshoot this issue.

    Thanks!

    0
  • German Mosquera
    コメントアクション Permalink

    0
  • Brett - Community Manager
    コメントアクション Permalink

    Thanks German,

    I created a ticket on your behalf so our Customer Advocacy team can look into this.

    You'll receive an email shortly stating your ticket has been created.

    Cheers!

    0
  • Francois Beaulieu
    コメントアクション Permalink

    I wonder if the response will be a suggestion that we tell our customers to use Microsoft Edge instead. Although, that'll soon be Chromium-based as well, so... We're running out of compatible browsers here people!

    0
  • Alan Hirshberg
    コメントアクション Permalink

    Not to be too cranky, but you guys opened a ticket for me on the exact same issue on 12/17/2019 and there has been no movement. I don't see what creating another ticket does in terms of finding a solution. 

    1
  • John Niernberger
    コメントアクション Permalink

    Three examples of this in the last 24 hours: yesterday, I was unable to login to Zendesk (owner account) from mobile safari (iOS).  Chrome worked fine.

    Earlier today, helped two of our agents.  One was using Brave, once she allowed cookies it let her verify her email.  Initially at least she was receiving a blank login page, so did not have an idea that it was a cookie issue.

    The more troublesome Safari issue is another agent couldn't login.  We looked at privacy preferences: Safari 'Block all cookies' was unchecked.  When she went into 'Manage website data' for Zendesk, 'Cache, cookies, Local Storage...' (etc) was all there as it should be.  She 'Removed' the site at this point, and it didn't seem to make a difference.

    Based on the other agent's feedback, she installed Brave, and allowed all cookies, and was able to verify her email.  At that point, she tried logging in with Safari, and this time it worked.  Not sure if it was the fact that once her account was verified she was allowed in, or whether removing the site from Safari's privacy preferences actually did the trick.

    0
  • Pepijn Van Eeckhoudt
    コメントアクション Permalink

    Seconding that sentiment Alan. I opened a ticket for this on 11/25/2019 and all I got as a 'solution' so far was to try clearing my browser's cache.

    The root cause of the problem is that the login page counts on cookies bound to `zendesk.com`. When you enable host mapping the login page still tries to use the `zendesk.com` cookie even though you're accessing it from a completely different domain. You then get errors in Safari like:

    Blocked a frame with origin "https://<domain>.zendesk.com" from accessing a frame with origin "https://<mapped host>". Protocols, domains, and ports must match.

    How hard can it be to get this fixed...? Don't use host mapped domains for the sign-in page, load the iframe using the mapped host name, whatever works. I saw reports of this problem on twitter more than half a year ago. You would think getting login working would be a high priority issue.

    1
  • Francois Beaulieu
    コメントアクション Permalink

    > The root cause of the problem is that the login page counts on cookies bound to `zendesk.com`.

    Precisely! There are also elements of the login form that use the zendesk.com domain as well, which completely screws up password management tools like LastPass, especially if you have multiple different Zendesk accounts!

    Other sites seem to manage this correctly, without 3rd-party cookies, so it has to be an implementation-specific problem.

    0
  • Steve Wolaver
    コメントアクション Permalink

    This whole issue is so frustrating. 

    1
  • Brett - Community Manager
    コメントアクション Permalink

    Hey everyone,

    Thank you so much for taking the time to share this information with us. I completely understand your frustration and will do everything I can to ensure you've been updated on our findings regarding this issue. While currently, I don't have any substantial information to provide, I do want to let you know that our security developer team is hard at work investigating these reports. 

    I'll be sure to follow-up with each of you here once I've found out more information. Thanks again for your patience while we look into this further!

    0
  • Mark Jared
    コメントアクション Permalink

    Probably has been stated in previous messages, but it appears that the signing in is no longer possible in Safari's private window either. If it's possible to turn this into a ticket as well for tracking, please do so. I, along with most others above, would greatly prefer this issue be resolved for those whose work is done exclusively using Safari. 

    0
  • Brett - Community Manager
    コメントアクション Permalink

    Hey Mark,

    As requested, I've created a ticket on your behalf. Our Customer Advocacy team will follow-up with you to gather more information.

    Cheers!

    0
  • Janiece Caldwell
    コメントアクション Permalink

    Wow I thought I was the only one having this issue! Please create a ticket for me as well. We pay so much money for ZD and its too bad that its not fixed quickly.

    0
  • Brett - Community Manager
    コメントアクション Permalink

    Hey Janiece,

    Thanks for the heads up! I've gone ahead and created a ticket on your behalf as well.

    Cheers!

    0
  • Vyacheslav Skorbezh
    コメントアクション Permalink

    Hey Brett,

    This incident hasn't been closed yet? 

    2
  • Adam Reid
    コメントアクション Permalink

    Hi Brett,

    We are also experiencing issues with this for some of our customers using Chromium and Brave browsers. This is a screenshot of the errors some of our customers are experiencing when trying to login to our Help Center.

    The error is 'Refused to display https://<company>.zendesk.com/access/login' in a frame because it is set 'X-Frame-Options' to 'SAMEORIGIN'.

    If you could please create a ticket on our behalf to track this, we'd like an update as soon as there is a fix.

    1
  • Brett - Community Manager
    コメントアクション Permalink

    Hey Adam,

    Thanks for the heads up! I've created a ticket on your behalf as well.

    @Viacheslau, our developers are still looking into a fix related to this issue.

    0
  • Christian Häfner
    コメントアクション Permalink

    Brett, can you please also open a ticket for me? I have the same issue. Users can´t log in on https://support.happycoffee.org/hc/de due to cookie restrictions. 

    0
  • Brett - Community Manager
    コメントアクション Permalink

    Hey Christian,

    As requested, I have opened up a ticket on your behalf.

    Cheers!

    0
  • Ryan
    コメントアクション Permalink

    @Brett - our clients are having the same issue.  Can you open a ticket to keep us posted on this too?

    1
  • Ward Clark
    コメントアクション Permalink

    Brett, when you create a ticket for Ryan, please add one for me ... and the hundreds (thousands?) who don't know about this Zendesk Help topic.

    0
  • John Niernberger
    コメントアクション Permalink

    😂 We just onboarded a new agent this morning and they had the same Safari issue lol, thought they were bringing it to our attention.  We were like "yeah check out this year old ticket here.  We've all been there done that." 

    Then comes Ryan's post just a few minutes later, had a good laugh about that.

    2
  • Noah Mehl
    コメントアクション Permalink

    Let me just save everyone the trouble.  Even if you open a ticket, they will just respond and tell you to subscribe to this reference article:

    https://support.zendesk.com/hc/en-us/articles/360034788653-Zendesk-support-for-Intelligent-Tracking-Prevention-ITP-in-Apple-Safari-browsers

    And then they will close the ticket, as if this were solved...

    0
  • Devan
    コメントアクション Permalink

    Hello Noah Mehl

    A workaround that you can do to resolve this issue is by setting the Chrome://flags/#same-site-by-default-cookies flag to disabled for the meantime.

    We currently need to disable SameSite default by cookies, because Chrome rolled out an update that blocks cookies without cross-site requests if they are not set with ‘SameSite=None’ and ‘Secure.’ However, last April 3, they recently did a rollback of this update for Chrome 80 in light of global circumstances due to COVID-19. For more details about it, you may check this article: Chrome's SameSite Updates

    I hope this helps! Let me know if you have further questions or clarifications.

    Best regards.

    0
  • Noah Mehl
    コメントアクション Permalink

    Devan I'm familiar with how to adjust browser settings to: make them less secure.  That's not a solution for the actual problem, which is a cross-domain cookie implementation.  Not to mention, I don't control the browsers of all of my clients, so, this is moot for them.

    1
  • Tobias Linder-Geiger
    コメントアクション Permalink

    Totally agree with Noah Mehl here! Devan is not a solution but a way to make the browser less secure.

    Zendesk should help us being better at solving the technical issues our users have and not create new ones! 

    I have a ticket open since October 8th. This is 6 months! I can't believe that we are paying 12'000 Euros a year for a solution that has such a serious bug and doesn't resolve it in a timely manner but we are locked in with so many workflows connected to the zendesk help portal.

    BTW: I requested again a status today and got the same answer like in January: The engineers war working on a solution but there is no ETA.

    1

投稿コメントは受け付けていません。

Powered by Zendesk