rp
11/21/2022, 4:32 PMrp
11/21/2022, 4:33 PMJ0rdan
11/21/2022, 10:30 PMJ0rdan
11/21/2022, 10:31 PMJ0rdan
11/21/2022, 10:37 PMrp
11/22/2022, 3:23 AMcrro
11/22/2022, 7:26 AMError: no host specified in headers or uri
crro
11/22/2022, 7:26 AMcrro
11/22/2022, 7:27 AMcrro
11/22/2022, 7:27 AMcrro
11/22/2022, 7:27 AMcrro
11/22/2022, 7:29 AMrp
11/22/2022, 7:48 AMJ0rdan
11/22/2022, 11:33 AMlazzySamurai
11/22/2022, 12:02 PMrp
11/22/2022, 12:03 PMinmesh
11/22/2022, 12:30 PMrp
11/22/2022, 1:10 PMITEnthusiasm
11/22/2022, 1:30 PMSuperTokens.init
(once)
2) cors
middleware
3) SuperTokens middleware
4) SuperTokens error handling middleware
The reason I ask is that as more SSR frameworks come out (e.g., SolidStart, SvelteKit, etc.), I'm realizing that a lot of tools -- even some of Auth0's tools -- are restricted by the fact that they're expecting to be run directly on some kind of server (e.g., an express server).
Of course, they are running on some kind of server. But the SSR frameworks try to abstract all of that away. This makes it hard (if not impossible) to apply the security logic which SuperTokens applies. These frameworks have "middleware-like" logic that can be supplied, but oftentimes this is incompatible with "real middleware".
Obviously this has been a problem for other similar auth options so far. But if SuperTokens were able to provide a way to integrate with these frameworks universally (or maybe a way can already be found from the codebase), it would have an edge on the other options -- at least as far as the crazy JS ecosystem is concerned.nosmaster89
11/22/2022, 1:32 PMLeander
11/22/2022, 1:36 PMdamian_w
11/22/2022, 5:53 PMrp
11/22/2022, 6:08 PMJ0rdan
11/22/2022, 8:34 PMyohanyflores
11/22/2022, 9:55 PMJoe P
11/23/2022, 4:08 AMJoe P
11/23/2022, 4:09 AMJoe P
11/23/2022, 4:16 AMJoe P
11/23/2022, 4:16 AM