SvelteKit Authentication not working on Safari

[tguelcan]

I very much hope for your support. My application works without problems, but the login via the browsers of mobile devices does not work. Nothing happens after the login and the redirect.

• I have implemented sveltekit auth according to the instructions.
• i have also compared the example.

Repo

Is this problem already known? Thanks a lot!

{
	"name": "myapp",
	"version": "0.0.1",
	"type": "module",
	"scripts": {
		"dev": "vite dev --port 3000",
		"build": "vite build",
		"package": "svelte-kit package",
		"preview": "vite preview",
		"prepare": "svelte-kit sync",
		"check": "svelte-check --tsconfig ./jsconfig.json",
		"check:watch": "svelte-check --tsconfig ./jsconfig.json --watch",
		"test": "playwright test",
		"lint": "prettier --check --plugin-search-dir=. . && eslint .",
		"format": "prettier --write --plugin-search-dir=. .",
		"start": "node build/index.js"
	},
	"devDependencies": {
		"@playwright/test": "^1.22.2",
		"@sveltejs/adapter-node": "1.0.0-next.81",
		"@sveltejs/kit": "next",
		"@tailwindcss/typography": "^0.5.4",
		"autoprefixer": "^10.4.7",
		"daisyui": "^2.19.0",
		"eslint": "^8.16.0",
		"eslint-config-prettier": "^8.3.0",
		"eslint-plugin-svelte3": "^4.0.0",
		"mdsvex": "^0.10.6",
		"postcss": "^8.4.14",
		"postcss-load-config": "^4.0.1",
		"prettier": "^2.6.2",
		"prettier-plugin-svelte": "^2.7.0",
		"svelte": "^3.44.0",
		"svelte-check": "^2.7.1",
		"svelte-preprocess": "^4.10.7",
		"tailwindcss": "^3.1.5",
		"typescript": "^4.7.4",
		"vite": "^3.0.0"
	},
	"dependencies": {
		"@supabase/auth-helpers-svelte": "^0.4.5",
		"@supabase/auth-helpers-sveltekit": "^0.6.8",
		"@supabase/supabase-js": "^1.35.4",
		"@tiptap/core": "^2.0.0-beta.182",
		"@tiptap/extension-placeholder": "^2.0.0-beta.53",
		"@tiptap/starter-kit": "^2.0.0-beta.191",
		"@tiptap/vue-3": "^2.0.0-beta.96",
		"html-to-text": "^8.2.0"
	}
}

[akiarostami]

Hi @tguelcan,

I'm facing the same issue and was wondering why you closed this? Did you solve the problem?

[tguelcan]

@akiarostami in the meantime, the issue had actually disappeared. currently, it is present again without me having changed anything in the authentication.

The issue now also appears on safari desktop. For me, the redirect to safari does not work at all.

[tguelcan]

I found out that it does not send the cookie in the user post when authenticating after the callback at safari.

[silentworks]

Can this be reproduced in any of the example projects?

[tguelcan]

I have found the issue in my case

If you use a service worker: The service worker caches the new incoming token. Either you clear the cache on logout or (as in my case) you ignore the #access_token. Strange that safari does so.

Here my whole service-worker: ./service-worker/index.ts

// based on https://github.com/tretapey/svelte-pwa/blob/master/public/service-worker.js
import { build, files, version } from '$service-worker';

const worker = self;
const CACHE_NAME = `static-cache-${version}`;

const to_cache = build.concat(files);

worker.addEventListener('install', (event) => {
	console.log('[ServiceWorker] Install');

	event.waitUntil(
		caches.open(CACHE_NAME).then((cache) => {
			console.log('[ServiceWorker] Pre-caching offline page');
			return cache.addAll(to_cache).then(() => {
				worker.skipWaiting();
			});
		})
	);
});

worker.addEventListener('activate', (event) => {
	console.log('[ServiceWorker] Activate');
	// Remove previous cached data from disk
	event.waitUntil(
		caches.keys().then(async (keys) =>
			Promise.all(
				keys.map((key) => {
					if (key !== CACHE_NAME) {
						console.log('[ServiceWorker] Removing old cache', key);
						return caches.delete(key);
					}
				})
			)
		)
	);
	worker.clients.claim();
});

self.addEventListener('fetch', (event) => {
	if (event.request.url.indexOf('access_token') > -1) {
		return;
	}
	console.log('[ServiceWorker] Fetch', event.request.url);
	if (event.request.mode !== 'navigate') {
		return;
	}
	event.respondWith(
		fetch(event.request).catch(() => {
			return caches.open(CACHE_NAME).then((cache) => {
				return cache.match('offline.html');
			});
		})
	);
});

[thorwebdev]

@tguelcan with your workaround, are we able to close out this issue, or do you still consider this a bug? I'm going to close it, but please reopen if you consider this still needs to be adressed. Thanks.