This article describes Zendesk support for popular, industry-standard browsers that restrict how cookies are recognized and used. Browsers that restrict cookie usage include recent versions of Apple Safari, Google Chrome, and Mozilla Firefox.
To prevent any issues caused by signing into Zendesk from a cookie-restricted browser, Zendesk has a streamlined sign-in process for the agents and end users who work on accounts with host-mapped domains.
To sign in
- For agents and end users, click the Sign in link in your help center.
A sign-in page appears.
- Enter your sign-in credentials.
For end users, sign in with a username and password, or use a social or business account to sign in. For agents, click I am an Agent to sign in.
- After signing in, agents and end users are automatically directed to the appropriate page in their account.
Agents will see their agent dashboard where they are signed in and can work on tickets.
End users will return to their help center as a signed-in user.
Stepping back a bit to understand if there’s something I’m missing in this discussion:
Login on hostmapped accounts using Firefox and Safari (including iOS) leverage the Storage Access API flow (implemented in H2 2020) - this is called out in this article and is a flow that takes the user through explicitly allowing a Zendesk cookie to be dropped and accepting it allows the user to log in. Nothing should be broken here and users should be able to log in. If the issue is that this flow isn’t working and you’re still not able to log in, that’s something we need to get more details on and understand what’s not working.
If the issue we’re discussing is the fact that we have this Storage Access API flow at all; I do agree that the login flow shouldn’t rely on third-party cookies and it is our intention to remove the use of them across the platform. We’re currently working through a couple of options and putting those forward for validation, once we have more insight there I will bring proposals to this group for feedback as well.
@... Thanks so much for jumping in here and sharing the steps you took to log in!
@... and @... Appreciate both of you clarifying that the workaround provided is indeed not working for you and I think that's where the confusion was coming from! I'm going to create a ticket for both of you so we can look at this internally and figure out why exactly it's not working. You both will receive an email shortly stating your ticket has been created so if you do have any additional information to provide feel free to reply back to that email.
I understand this can be frustrating but do know we hear you and we appreciate you sharing your concerns with us!
@... Just want to confirm with you as well, is the issue that the work-around provided in the above article is not working for you either? If so, I can create a ticket for you and get it assigned over to the appropriate team.
Let me know!
The workaround is LITERALLY ALLOWING CROSS-SITE TRACKING.
I will not do that. It's not an acceptable path for me, or for my customers. So no, it's not "working".
Until & unless you change this expectation, there's no point in you creating a ticket for me.
Enabling cross site tracking is a completely unacceptable "work around" for many reasons. First and most obviously, Zendesk is asking its users to degrade the security of their ENTIRE BROWSING EXPERIENCE across all websites. Second, it requires end users to follow a convoluted process to implement the workaround which requires handholding from an agent. This makes it completely impractical for almost all of the use cases that are being complained about in this thread. It is just so obviously unacceptable that the mere proposal of it as the sole workaround (for years now) rises to the level of being insulting. The message being sent here again and again is that Zendesk doesn't care about the customers of its core product.
@Tiago Soromenho Correct, if the cookies are intact this is only a problem in Safari the first time you login. Of course cookies don't always remain intact and functional.
But yes, the Safari experience is better than other browsers when visiting a zendesk powered portal, but Chrome based browsers are still fully broken. I can't think of anything else in my daily workflows that are browser specific. This isn't 1990.
@Brett Bowser as best I can tell things are working as designed. The design is just poor.
As @Joseph Crivello said, requiring Enabling cross site tracking is a terrible approach that puts users at risk and undermines state of the art browser security.
Looking at my Chrome settings again, the problem could be that I have, "Block third-party cookies" set on. I don't recall if this is Chrome's default but I think that is what Chrome calls the Safari setting in @Tiago Soromenho's post.
So it is likely that if I am willing to lower security for all websites perhaps even Chrome can use this workaround. Since Chrome is my primary browser I will keep the setting where it is. But that forces me to compromise Safari and switch to it if I want to easily sign into a zendesk powered portal.
"Block third-party cookies" is indeed the default now for Chrome and Safari, and that's the crux of the issue. NO USER SHOULD TURN THIS OFF, FOR ANY SITE. Asking a user to do is absurd.
@... I - like the others - missed that the article here was updated with the new flow. I tested this locally and it seems to *mostly* work. The process seems a bit wonky (required some browser reloading) but given I also run macOS Monterey, it might just be a beta issue. After some trying it worked. The process and multiple tabs and reloads and alerts is everything but smooth though.
For the latest complaint I'll circle back why it didn't work for them - it is possible that it's an existing cookie that interferes here (like others mentioned as well), which again shows how fragile the current hack is.
I can also confirm that this hack works on iOS 15b3. (However, Twitter Auth seems broken there)
It is good to hear that future improvements are planned - logging into a support system shouldn't be so difficult.
@..., @... -- I think you guys are missing that this does NOT "allow cross site tracking" in a general manner. The "Allow Cross-site tracking" should remain OFF.
The issue here is that IF you access the Zendesk through a subdomain like "https://support.your-company.com" the actual service (Zendesk) is not where your domain is hosted. They need to set a cookie (which admittedly is old tech) with your session ID. They can't do that _because_ their servers are not associated with your domain, just one of your sub/domains is mapped to theirs.
The issue is that before, the browsers either allowed ALL cross-site tracking or NONE. What Apple has enabled in Safari now is to allow an exception to be made on a PER CASE basis. Clicking the "Allow" button on the pop-up does NOT enable ALL cross-site tracking.
Again, this is ONLY when the Zendesk service is exposed to you or your customers in a domain-mapped url like support.your-company.com. If you were to access Zendesk using their provided sub-domain with your company ID (usually your-company.zendesk.com) this is not an issue.
I spent years as a web developer. I understand what's going on, Tiago.
The stated workaround explicitly allows Zendesk to track visitors across the web. That's not an acceptable path for me, for my people, or for my customers.
Hi @... -- Do you have any evidence of your claim?
My understanding of the Safari documentation is that the exception is specifically to allow Zendesk.com to set a cookie on a customer's browser whose scope is your-domain.com. Meaning that only Zendesk can read your-domain.com cookies (and possibly only THAT cookie that it set itself, but that I'm not sure about.)
And specifically the paragraph (emphasis mine):
"Social media sites often put Share, Like, or Comment buttons on other websites. These buttons can be used to track your web browsing—even if you don’t use them. Safari blocks that tracking. If you still want to use the buttons, you’ll be asked for your permission to allow the site to see your activities on the other websites.
Hence I don't understand the mechanism by which you believe that Zendesk can track visitors across the web? Even if a customer (or a CSR) has visited your support.your-domain.com site has received a cookie from Zendesk whose scope is your-domain.com, and either go visit say, google.com or get-away-adventures.com, those sites _cannot_ access any cookie whose scope is your-domain.com, whether it was placed by your site or Zendesk.
The previous issue that we all had an issue with is that Zendesk needed to place a Zendesk.com scope cookie while the site accessed had a url/domain of support.your-domain.com and it needed the user to open up their cross-site tracking option in order for Zendesk to place and retrieve its own cookie on your site. With this new "exception" capability from Safari, this is no longer needed, and we can continue to keep our "cross-tracking" setting turned off, as it should be.
Hence, what am I missing that gives you the belief that they can track visitors across the web? Can you explain the mechanism you see at work here? I'm genuinely interested as it's very possible I am overlooking something.
Any x-site access is anathema to most people today.
Zendesk's failure here remains a problem.
Hi, all - I wanted to summarize what I hear to be the concerns raised in this thread. There are some very good concerns, and we know the current situation is not optimal.
Sign in on host mapped accounts was completely broken by changes made in certain browsers behavior. We’ve resolved this in late 2020 for Safari (incl. iOS), Firefox and Edge by using the Storage Access API. This has introduced a new experience during the sign in flow where we explicitly ask for permission to drop a Zendesk cookie only for the duration of your browsing. This does not require cross-site tracking to be enabled. This article has been updated to reflect this new experience.
This new sign in flow is not our end state solution. It’s been put in place to allow any sign in at all for Safari, Firefox and Edge browsers, given their new restrictions. We intend to fully cease using third party cookies as part of our login experience for host mapped accounts.
This will be a complex change and take time. We’re validating proposals at the moment, and will share progress with this thread. For now, login on host mapped accounts is not broken, but it’s suboptimal. We’re aiming to improve this, and we appreciate all your feedback along the way.
@... and @... - There's clearly a lot of opinions and frustrations being expressed in this thread so it's great to see your input and acknowledgement of the issue.
To my understanding, Chrome will be adopting similar changes as Safari and Firefox later this year. If true, this would mean the workflow created using the Storage Access API would need to be ported to Chrome as well. I guess my question is two fold:
It's my understanding that Google has delayed their plans for blocking third-party cookies until 2023, if they stick to that new timeline we will have our changes in place well before Chrome implements their restrictions. If for some reason they move the timeline earlier again, our best approach is to leverage the Storage Access API which I believe Chrome is adding support for.
@max, it is suboptimal for most browsers and broken for the browser with dominant market share. So really poor situation overall.
@... - I stand corrected. Thanks for sharing that link!
Using Firefox, the initial window comes up about cookies but when I click on Continue, it simply reloads the current page and does not take me to the secondary page to sign in. Therefore I'm stuck in a loop. I've checked my cookie settings and made adjustments but still get that same window repeat. I'm forced to use Chrome which is slow and slows down my computer significantly. How can I remedy this with using just Firefox?
Hey Mark - are you using Firefox on iOS?
I'm on a PC at work using Windows. I haven't had any issues at home on a MBP.
The “sub par” experience in Chrome on iOS where we had to do the tap dance between sites no longer works at all. Unless I’m willing to allow all third party access to all sites, I can’t login to zendesk portals at all as shown below.
After what two years of being broken, I don’t expect that this will be fixed anytime soon.
Works with Safari 14, but doesn’t work with Safari 12, the first Safari version to feature Intelligence Tracking Prevention 2.0, and hence that dialog box. What am I doing wrong?
Were you able to follow the suggested resolution provider under this article and still experience an issue? If yes, you may generate a HAR file and speak to our Customer Support immediately by initiating a conversation with us.
Thank you, Cheeny, but could you please tell me how can I contact any real people instead of a bot, which just keeps dumping me to login page?
Unfortunately, you need to be authenticated for us to check your account. Once authenticated, you will be able to connect to a live agent that will be able to troubleshoot your issue the soonest.
My yearly renewal for Zendesk is coming up and I am looking into alternatives. The issue with Safari and having to deal with multiple clicks and sign ins multiple times a day is killing my workflow and efficiency. This problem has been going on for over a year.
Tom Gaynor I think this issue is at least two years old. Unconscionable.
Max McCal and Caroline Kello Is there any status update on when we will return to an optimal login on host mapped accounts across major browsers with default security settings enabled?
Max McCal Caroline Kello When can we expect to see this resolved properly?
Asking our customers to turn off or add exceptions for 3rd party cookies is not merely suboptimal, it's something that most will simply not do, and both we and our customers suffer greatly as a result.
Please sign in to leave a comment.