Closed simurai closed 4 years ago
I tested on:
Seems to work fine:
The person reporting the issue is using:
So maybe it's an issue with an older OS version?
@antstorm are you by any chance still on El Capitan? Probably not.. 😄
http://www.giphy.com/gifs/xT0xeDQDvEXtiOTHH2 - File size too large to upload here
Went to your codepen on my iMac:
Ha.. interesting. Thanks for posting the gif.
So not really the OS then. Also interesting how it scrolls up/down after pressing enter.
@antstorm Any clue what it could be?
Sorry, that was me scrolling to show that it was not just hidden overflow or something.
On Nov 7, 2017 7:00 PM, "simurai" notifications@github.com wrote:
Ha.. interesting. Thanks for posting the gif.
So not really the OS then. Also interesting how it scrolls up/down after pressing enter.
@antstorm https://github.com/antstorm Any clue what it could be?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/tlkio/feedback/issues/2#issuecomment-342695585, or mute the thread https://github.com/notifications/unsubscribe-auth/AWX3__HSw_nE1dfdG16onFUgw8g2JA_dks5s0RlRgaJpZM4QVt3R .
Sorry, that was me scrolling to show that it was not just hidden overflow or something.
Ah.. I see. Ok, so then messages just don't get posted.
Are there any errors in the console of the web inspector (DevTools)?
Throws an error in the console every time I click send. Here's what I get:
This is what I get in the network tab: Response: { "error": "Unauthorized Access" } Request: { "body": "test", "expired": false } Note: the body matches what I wrote into the input box.
Pasting an earlier email:
Hi Warren,
I’ve spent some time trying to understand the underlying issue and it turns out that Safari no longer supports 3rd party iframe cookies. It is just dropping these, that’s why the messages won’t come through — they fail authentication on our side.
I’ve also tried implementing what seems to be the common solution for this problem — basically you open up a pop-up that sets a cookie, making the target website “familiar”, thus allowing cookies. But it doesn’t seem to work — seems like the newest Safari disabled these altogether. There is a setting in Safari that will enable this behaviour, depending on your use case it may or may not be a solution for you.
As for the permanent fix — seems like we’ll need to use other means for session management within the iframe (something like JWT or a self-signed token). I’ll start working on this straight away, but I won’t be able to commit to releasing it this Thursday.
Really sorry for this inconvenience. I’ll ping you on the progress within a couple of days.
@warrendugan @simurai what do your cookie settings in Safari look like? Here's mine:
I don't remember ever changing this. If this is the current default then there's no simple fix.
Here's a demo of the fix (which doesn't work for me because of my settings) — http://vitr.github.io/safari-cookie-in-iframe/demo.html. When you click on the "fixed page" it should say that cookies work.
If it's just my settings that are off then there is a quicker fix for this problem.
This is what I get:
I have the same settings as @warrendugan ☝️ .
But now I know why tlk.io worked for me even after updating to High Sierra. It's because it still used the cookies saved from the previous Safari version. After removing them...
the chat doesn't show up anymore. So it should still work in Safari for people that used tlk.io in the past, but not for new users (or when deleting the cookies).
@simurai so it doesn't show up at all? Or you just can't post messages?
Yeah, seems like we'll need to find a way around it. It seems like you can manually access parent window's cookies, which might be a solution.
It doesn't show up at all:
Failed to load resource: the server responded with a status of 404 (HTTP/2.0 404) https://tlk.io/embed.js
But this is probably another issue. It also happens in Chrome and Firefox. Sounds the same as:
This is really weird! Can you access https://tlk.io/embed.js directly in your browser?
I wonder if HTTP/2.0
has to do anything with it…
I get a 404:
Or maybe a caching/CDN issue? I think I remember something like deleting tlk.io's cookies in Chrome and refresh a 2nd time until I saw the issue.
Hmm… really odd. We don't use CDN, the files should be served directly. What if you try requesting it from the console directly curl -I https://tlk.io/embed.js
?
I'm able to access https://tlk.io/embed in Safari and Chrome but not with the .js after it. Also, I'm able to send and receive messages in Safari and Chrome on that URL.
Ohh.. now https://tlk.io/embed.js works again for me. 👍 Also https://codepen.io/anon/pen/ooYNaV works fine. In both, Safari and Chrome. Weird eh?
Ok, so the issue with https://tlk.io/embed.js should now be resolved and it should return a JS file. @warrendugan can you please confirm this?
@simurai totally weird! It might be that Safari will allow to use the cookie that was when visiting the embedded webpage directly. The most popular solution for this issue also suggested opening a popup to your website, setting the cookie, immediately closing it and then reloading the iframe. Which should probably work, but UX in this case would be awful, not to mention the iPhone experience.
I'm looking into solutions to resolve cookies issue.
Apple has added further restrictions to its "Intelligent Tracking Protection" and now blocks cross-site cookies completely. These blog posts point to some alternative methods which developers can use instead -- not sure if they will apply to tlk.io.
https://www.theverge.com/2020/3/24/21192830/apple-safari-intelligent-tracking-privacy-full-third-party-cookie-blocking https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/
@brettdonald thank you for linking these! 👍 Unfortunately the ones I've read so far were not very clear, but maybe these are better
could you use local storage instead of cookies?
On 28 May 2020, at 8:12 am, Anthony Dmitriyev notifications@github.com wrote:
@brettdonald thank you for linking these! 👍 Unfortunately the ones I've read so far were not very clear, but maybe these are better
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
@brettdonald local storage is not passed back to the server, which makes it unusable for authentication purposes. I've just posted another fix and tried it out and it seems to be working correctly, can you please check if that also works for you?
I'm on Mac OS X 10.15.4, Safari 13.1 (15609.1.20.111.8)
Yes, it works! That's fantastic! I'm on macOS 10.14.6, Safari 13.0.3 (14608.3.10.10.1). Thanks so much for your time working on this. I think you can mark the issue as resolved/closed.
Can you describe briefly the changes you had to make? Have you fundamentally changed the way tlk.io works, or did you add a separate code path for Safari, and keep the code the same for all other browsers?
@brettdonald this is great, thank you for confirming! 👍
Basically I had to call hasStorageAccess
and requestStorageAccess
APIs (only Safari supports these right now as far as I know) to explicitly request the use of cookies from the client's browser. This has to be done on user action making the intent obvious.
No fundamental changes were necessary, but there was some confusion in how those APIs work and the amount of information on this issue is unfortunately limited. Here's a good thread on the matter — https://gist.github.com/iansltx/18caf551baaa60b79206