Browser ondersteunt pushnotificaties, maar niet op subdomein

[HollowGamer]

Je browser ondersteunt pushnotificaties, maar niet op subdomeinen. Bezoek een willekeurige pagina op tweakers.net om pushnotificaties te activeren.

Dit is meer een vraag, omdat ik benieuwd ben hoe jullie dit (zouden) oplossen.
Aangezien ik meerdere devers hier mee zie stoeien en Google/SO vol staan met dit soort topics.

Naar mijn weten is er tegenwoordig CORS, daarmee geef je aan welke domeinen/wie met elkaar mogen communiceren. Dus in theorie zou je mogen zeggen met een CORS-header(s) dat gathering.tweakers.net headers mag plaatsen uit naam van tweakers.net. 'Vroeger' kon je * opgeven als zijne uit naam van iedereen, maar ik dacht dat de meeste browsers dit niet meer toestaan tegenwoordig.

Waarom krijg ik precies die melding? Komt het doordat jullie een cookie plaatsen voor die pushmeldingen?
Of speelt iets anders mee?

Als (web)devel hoor ik graag meer, zeker om ervan te leren.

Thanks!

[crisp]

CORS heeft hier niets mee te maken, dat is voor cross-(sub)domain requests. Cookies zijn hier ook het probleem niet, want die kan je vanuit een subdomain prima op .domain.com zetten. Het probleem is de serviceworker die je moet instantiëren vanaf een pagina met dezelfde origin als het script van de serviceworker, maar je wilt niet voor elk subdomain een aparte serviceworker.

Wat wij proberen is om het op gathering.tweakers.net via een iframe te doen die we laden vanaf tweakers.net. Door 'domain relaxation' te gebruiken kan je communiceren met deze iframe en een serviceworker vanuit de iframe starten. Uiteraard kan je dit ook mbv postMessage faciliteren (document.domain als setter is eigenlijk deprecated, en wellicht zijn er al browsers die het niet meer ondersteunen).

Nu is deze workaround ook niet helemaal fool-proof; de melding die je krijgt over subdomeinen kan ook zijn omdat je al eerder op tweakers.net notificaties simpelweg geblokkeert had (maar dat kan je ook niet fixen vanaf het subdomein).

[HollowGamer]

Waarom gebruiken jullie niet één domain en serveren vanaf daar de services (sockets, API, etc.). Dus bijvoorbeeld vanaf iets als https://api.tweakers.net/?

Jullie hoeven technische zaken niet te delen, ben gewoon benieuwd.

[crisp]

HollowGamer schreef op zondag 5 juni 2022 @ 17:33:
Waarom gebruiken jullie niet één domain en serveren vanaf daar de services (sockets, API, etc.). Dus bijvoorbeeld vanaf iets als https://api.tweakers.net/?

Jullie hoeven technische zaken niet te delen, ben gewoon benieuwd.

Dat we een subdomein voor het forum gebruiken komt voornamelijk omdat het heel vroeger technisch helemaal losstond van de rest van de site en 3rd-party software was. We zouden het nu naar iets als tweakers.net/forum kunnen omzetten, maar het gathering subdomein is eigenlijk een stukje legacy die we willen behouden.

Met je opmerking mbt services vanaf een api-endpoint doel je denk ik op een web-application, of zelfs een SPA? Tsja, zo is Tweakers nu eenmaal niet opgezet. Ook hier speelt legacy een rol, maar in mijn ogen hoeft ook niet alles een web-app te zijn; het biedt niet altijd voordelen voor een website waar je ook gewoon serverside HTML kan genereren.

[HollowGamer]

Serverside heeft deze voordelen, maar ook genoeg nadelen.
Een SPA is erg flexibel, met iets als Livewire bestaan er zelfs een soort hybrid alternatief.

Maar ik bedoelde meer als vanaf alle services aan te bieden over één url, dat hoeft nog niet eens over een subdomain te zijn. Denk dat je dit ook bedoeld.

Ik ben vrij nieuw met een serviceworker, wat is precies daar het voordeel van? Zo te zien registreer je wat gecached mag worden op de cliënt en registreer je een bepaalde worker. Het ziet er aardig gecompliceerd uit, maar zo te zien blijft het wel actief tussen het navigeren van pagina's?

Zijn websockets niet flexibeler? Dan hoef je toch niet meerdere workers te initiëren? En deze kan je dan serveren via een proxy.

Ben nieuw met dit soort dingen, ben gewoon benieuwd.

[crisp]

HollowGamer schreef op zondag 5 juni 2022 @ 18:13:
Serverside heeft deze voordelen, maar ook genoeg nadelen.
Een SPA is erg flexibel, met iets als Livewire bestaan er zelfs een soort hybrid alternatief.

Het grootste nadeel van een SPA is dat je overal het wiel opnieuw voor moet uitvinden: SEO, bookmarkability, history management. Sure, daar heb je frameworks voor, maar daar moet je dan ook de kennis en ervaring voor in huis hebben, plus dat de life-span van dergelijke frameworks vaak beperkt is.

Maar ik bedoelde meer als vanaf alle services aan te bieden over één url, dat hoeft nog niet eens over een subdomain te zijn. Denk dat je dit ook bedoeld.

Dat zou eea wel eenvoudiger maken technisch gezien. Wellicht dat we het voor het forum toch ooit nog wel gaan doen...

Ik ben vrij nieuw met een serviceworker, wat is precies daar het voordeel van? Zo te zien registreer je wat gecached mag worden op de cliënt en registreer je een bepaalde worker. Het ziet er aardig gecompliceerd uit, maar zo te zien blijft het wel actief tussen het navigeren van pagina's?

Zijn websockets niet flexibeler? Dan hoef je toch niet meerdere workers te initiëren? En deze kan je dan serveren via een proxy.

Ben nieuw met dit soort dingen, ben gewoon benieuwd.

Een serviceworker kan inderdaad in de achtergrond zaken regelen zelfs zonder dat je de site open hebt in een browserpagina. Het is een voorwaarde voor het gebruik van de Push API.