ITEnthusiasm
12/06/2022, 6:06 PMIssue
I threw up on GitHub in supertokens-node
. But this question is more specific.
Is there an existing way to replicate the /signin
, /signup
, /session/refresh
route middleware by hand? (And are those the only middlewares created from app.use(middlewares())
?)
(Background in Thread)
remix-supertokens
example that I created works just fine. However, there are limitations: The current implementation relies on calling `http://localhost`/`https://localhost`. If, for some reason, the web server decides to force https
only, then when the Remix server calls itself, it must also use https
.
My application is constrained in this way:
1) I can't make requests to https://localhost
from my own server.
2) I can make requests to https://MY_DOMAIN.com
from my own server.
3) I don't want to make requests to https://MY_DOMAIN.com
from my server because it creates unnecessary round trips and will cost me more money.
(I could go into the details of why I'm in that situation, but I figured that listing out the constraints was simplest.)
Being in this conundrum, I'm now trying to see if there's a way to replicate the SuperTokens functionality on the server directly in my Remix Actions (i.e., "route handlers").rp
12/08/2022, 5:51 AMITEnthusiasm
12/08/2022, 1:42 PMrp
12/08/2022, 1:43 PMITEnthusiasm
12/08/2022, 1:47 PMrp
12/08/2022, 1:48 PMITEnthusiasm
12/08/2022, 1:51 PMhttps://mydomain.com
), then the request would go to Cloudflare (not my origin server), which has valid certificates. But that's an unnecessary round trip that I don't want to take.
For clarity:
- Cloudflare has valid CA certificates. (Node.js trusts these.)
- Origin Server has Cloudflare-signed certificates that Cloudflare trusts, but that Node.js does not. This is typically fine, except for cases where the Node.js server tries to call itself directly through localhost
. (Ironically.)rp
12/08/2022, 1:52 PMITEnthusiasm
12/08/2022, 1:54 PM443
is exposed by the server.
Because of this, I cannot call http://localhost
. That would be an HTTP request, which the server rejects.
Now imagine that on the server, I'm using a self-signed certificate in the configuration. Browsers do not trust this certificate. Similarly, no Node.js application will trust this certificate. If someone else tries to call my server using HTTPS (e.g., https://mydomain.com
), Node.js will fail the request because the certificate is not verifiable. In the same way, if I call https://localhost
, Node.js is still unable to verify the self-signed certificate. So even though the server is calling itself, it will fail.rp
12/08/2022, 1:59 PMITEnthusiasm
12/08/2022, 2:03 PMserver.js
file in that case. It doesn't bleed into things like certificate authorities and such. And it doesn't require something else like Nginx. (Unrelated: This would also give me a hint to translate all my Remix-SuperTokens code to a new Solid-Start example, I think.)rp
12/08/2022, 2:04 PMITEnthusiasm
12/08/2022, 2:05 PMrp
12/08/2022, 2:05 PMITEnthusiasm
12/16/2022, 4:24 PMrp
12/16/2022, 4:28 PMITEnthusiasm
12/16/2022, 6:03 PMsupertokens.middleware
points. https://github.com/supertokens/supertokens-node/blob/master/lib/ts/framework/express/framework.ts#L159 ๐คsupertokens.middleware
> recipe.handleAPIRequest
, it seemsIncomingMessage.headers
, right?any
in many places admittedly makes some aspects of looking around the code and contributing a little difficult. ๐
attachCreateOrRefreshSessionResponseToExpressRes
. Is this the only function used to create the Access+Refresh tokens?
If the answer to Question 2
is yes (I hope it is ๐ฌ), is there a way that we can update this (and the related functions) to avoid manipulating the original Response
object and to return the ResponseHeaders
necessary for SuperTokens to properly do its auth stuff only?app.use(middleware())
, I'm finding that it would actually be a lot better if I could use a framework-agnostic solution... A framework-agnostic solution is the only way to support the neat frameworks like SvelteKit and Solid Start right now. And it will guarantee that all new hot SSR frameworks that appear in the future will immediately be supported. Being able to support next@13
when the app
directory is out of beta would also be a big deal.
Of course, the code would also need to be updated to accept Request information instead of the entire request object. Where needed, SuperTokens could probably accept a `RequestContext`/`RequestData`/etc. object that has any needed information path
, body
, etc. (I'm hoping that SuperTokens doesn't need that much request information -- to keep life simple.)BaseRequest
, BaseResponse
, and all of their child classes. I know this isn't necessary and would be a breaking change, but I think it would thoroughly benefit the SuperTokens team and all contributors. The team wouldn't need to maintain several abstract
classes and sub classes anymore because end-users would simply interact with the Recipe.*
and Session.*
methods directly. And contributors would be able to make contributions more easily. (I personally felt like I was hopping back and forth a lot around the codebase to get only a super basic idea of what the signup
route does just for Express. And not all types were defined. That will probably be a barrier to some people who would otherwise contribute. It was a barrier to me until I found out I really need this feature and SuperTokens can get a 1-Up on Auth0 with this. ๐
)
It's a short term bother with huge long term benefits. And the docs could just be updated to show how to implement the API routes in each framework. I imagine it wouldn't be that hard.
Just spitballing more thoughts. I can add this to the original issue I opened too if that would be more helpful. But I think the next step would really be to add a feature for framework-agnostic solutions by refactoring those underlying classes I mentioned. Lmk your thoughts. Sorry I know I typed a lot.rp
12/17/2022, 1:35 PMres
object, and the middleware
also takes in a req
and res
object (like middleware()(req, res, next)
. Instead of giving it the actual req
, res
objects, you can instead make your own "fake" req, res objects and pass those in. Then later on, you can read from the fake res object the headers / cookies that were set and do whatever you like.
The fake req
, res
objects would have to conform to the BaseRequest and BaseResponse shape and would need to have the boolean of wrapperUsed
as true.
--------------------
So even now, it's technically possible to use SuperTokens with any framework via the above method. You could even use this trick to convert a form post request from the frontend to a JSON request that's understandable by the supertokens API and this would make is so that in the remix backend, you don't have to send a request to the backend itself (which i believe you are doing now).
We will make this more easy / document this in the future.ITEnthusiasm
12/19/2022, 2:38 PMcreateNewSession
will allow me to read those tokens and add them to my own separate response object. I can send my own [req] object in as long as it has the data needed. Sound correct?
Is `ExpressRequest`/`ExpressResponse` internal or is it exposed by the npm package? I'm assuming that reusing those classes would make it easier to do this. If so, maybe I can trying seeing if I can bring that logic to remix-supertokens
-- depending on how it would impact code readers. I'd have to see what the physical code turns out to look like first.
---
Long term though, any thoughts on refactoring some of those internal functions to simply receive data and return a response headers object or something? The workaround you described sounds like it should work. But it will leave the SuperTokens team with maintaining some logic that's more complex; and it will require end users in situations like mine to jump through more hoops. It's more effort for everyone to wrap their brains around things.rp
12/23/2022, 2:26 PMres
object that you give it. So you can provide a custom res object that conforms to the BaseResponse structure, and then can read the tokens from that to set however you like.
> Is ExpressRequest/ExpressResponse internal or is it exposed by the npm package?
It's internal.
> Long term though, any thoughts on refactoring some of those internal functions to simply receive data and return a response headers object or something?
Yes.
> But it will leave the SuperTokens team with maintaining some logic that's more complex;
It won't affect us in terms of additional code maintenance, since you are creating your own res / req object anyway.ITEnthusiasm
12/23/2022, 2:33 PMrp
12/23/2022, 2:34 PMITEnthusiasm
12/29/2022, 6:34 PMcreateNewSession
if not.request
inputs with simple request data inputs and replace response
inputs with an output of response Headers
.
But it seems like createNewSession
or attachCreateOrRefreshSessionResponseToExpressRes
would be sufficient candidates since that's where the interaction with the response is going on.getCookieValueToSetInHeader
(https://github.com/supertokens/supertokens-node/blob/a8760b966dd1239f0e7b782b72bbfba830fcd859/lib/ts/framework/utils.ts#L300). All of the let
fun is making it hard to follow the logic. ๐
Does this function basically set a new value for a cookie if it doesn't exist yet and replace the value for a cookie if it already exists?~~
**Edit**: You can ignore this. I'm pretty sure the answer to my question is yes.Set-Cookie
, I believe.front-token
represent? I've never seen it set in my apps. Is it only set when the frontend needs JavaScript?login
working now. If this is good to go, I think I'm gonna start targetting signup
and refresh
.rp
12/30/2022, 5:37 AMITEnthusiasm
12/30/2022, 2:21 PMrp
12/30/2022, 2:22 PMITEnthusiasm
12/30/2022, 2:51 PMsigin
, signup
, createToken
, and resetPassword
all inside handleRequest
. But I don't see anything for logout
or refreshToken
. Do you know where this logic is defined within supertokens-node
?rp
12/30/2022, 2:51 PMITEnthusiasm
12/30/2022, 5:07 PMrevokeSession
returning true
vs false
?logout
because the incoming sAccessToken
that's needed for the initial Session.getSession
call appears to be URI encoded.SuperTokens
/signout
route automatically run decodeURIComponent
on the sAccessToken
? (I didn't see any logic doing this on the supertokens-node
repo ... but decoding the token seems to be required for the code to work.)headers.get("anti-csrf")
was returning null
instead of undefined
. Changing to headers.get("anti-csrf") ?? undefined
makes the code work.
**Question 3**: What's causing that to break? Can SuperTokens not work with both undefined
and null
here?signUp
tomorrow. But after that, I'd appreciate some review to make sure the things that I've written actually work as expected (if that wouldn't be a bother) -- similar to what we did the first time I created remix-supertokens
. ๐
Assuming I can get signUp
working, I still don't know if I'd say SuperTokens "supports" things like SolidStart and SvelteKit. ๐
Once the developer needs knowledge of internals to get things working, it's no longer "supported". But I'm at least glad there's an option to cleverly interact with the internals.signUp
function as well (when I create it)? Or does EmailPassword.signUp
automatically take care of that for me?rp
12/31/2022, 5:24 AMITEnthusiasm
12/31/2022, 2:46 PMrp
01/01/2023, 6:06 AMITEnthusiasm
01/01/2023, 12:52 PMexperiment/custom-supertokens
branch of the remix-supertokens
repo to see the latest code: https://github.com/ITenthusiasm/remix-supertokens/tree/experiment/custom-supertokens.
The most important changes (at least right now) are in this last commit (if you want to look at diffs): https://github.com/ITenthusiasm/remix-supertokens/commit/f50eabc105885ddd024730f1f1652fa741204e23.
If you (and/or any other members) could review the code and test out the app to make sure everything is working correctly, that would be appreciated. Then, if you guys think it's a good idea, I can merge this into main
on the remix-supertokens
repo. (My hesitation is that there's a little more code that devs have to write to get their Remix
apps running. But people using Remix
in certain ways will end up forced to use this approach anyway.)
I'd especially appreciate it if you could let me know if there are any error cases that I'm failing to handle properly -- especially around the /logout
and /auth/session/refresh
routes. ๐
Thanks again for all your help in this. This thread is several comments long. ๐ If this works out, I'm probably going to do some minor cleanup here or there... Then after I take a break, I'll probably see if I can tackle SvelteKit
with this approach... maybe. ๐
But I'm only intending for these to be temporary workarounds since these solutions make assumptions about internal logic within supertokens-node
. It's a little dangerous.
In terms of the supertokens-node
refactors that could be done, maybe this code could give ideas about the potential inputs/outputs to require? idk. ๐คท๐ฟโโ๏ธ But from this experiment, it seems like the supertokens-node
functions/methods really only need request Headers
as inputs (instead of the whole request object); and it seems like supertokens-node
can return response Headers
instead of accepting and mutating a response object.Remix + Express
so I'm not sure what the Cloudflare limitations would be.getAllCORSHeaders
return? Is there a place where we can see the derivation logic? All the static methods I see on the repo just return empty arrays. ๐คrp
01/02/2023, 4:35 AMITEnthusiasm
01/02/2023, 5:46 PMrp
01/02/2023, 5:46 PMITEnthusiasm
01/05/2023, 2:09 PMnext@13
is also gradually adopting support for web-standard `Request`/`Response`. If they do this all the way, this approach will also work in Next.js without any additional refactoring. (Refactoring the approach to work with Next.js would be rather easy to do anyway though.)
Really glad Remix came along. It definitely pushed Next.js to make some better changes. ๐
rp
01/06/2023, 4:20 AMITEnthusiasm
01/10/2023, 2:12 PMcookie
package docs (https://github.com/jshttp/cookie#cookieserializename-value-options):
For the encode
option passed to `cookie.serialize`:
> Specifies a function that will be used to encode a cookie's value. Since value of a cookie has a limited character set (and must be a simple string), this function can be used to encode a value into a string suited for a cookie's value.
>
> The default function is the global encodeURIComponent
, which will encode a JavaScript string into UTF-8 byte sequences and then URL-encode any that fall outside of the cookie range.
Similarly, for the decode
option passed to `cookie.parse`:
> Specifies a function that will be used to decode a cookie's value. Since the value of a cookie has a limited character set (and must be a simple string), this function can be used to decode a previously-encoded cookie value into a JavaScript string or other object.
>
> The default function is the global decodeURIComponent
, which will decode any URL-encoded sequences into their byte representations.
>
> note if an error is thrown from this function, the original, non-decoded cookie value will be returned as the cookie's value.
So it seems the cookie
package that supertokens-node
uses automatically encodes and decodes. That's why I ran into that hiccup earlier.rp
01/10/2023, 2:15 PMITEnthusiasm
01/10/2023, 2:16 PMrp
01/10/2023, 2:18 PMITEnthusiasm
01/10/2023, 2:31 PMrp
01/13/2023, 5:49 AMts
export default function handleRequest(
request: Request,
responseStatusCode: number,
responseHeaders: Headers,
remixContext: EntryContext
) {
requestWrapper = createSuperTokensRequestWrapper(request);
responseWrapper = createNewSuperTokensResponse();
callbackCalled = false;
await middleware()(requestWrapper, responseWrapper, () => {
// this means that the middleware did not handle the request
callbackCalled = true;
})
if (callbackCalled) {
// this means that the middleware didn't handle it, so we let other routes handle it
let markup = renderToString(<RemixServer context={remixContext} url={request.url} />);
responseHeaders.set("Content-Type", "text/html");
return new Response("<!DOCTYPE html>" + markup, {
status: responseStatusCode,
headers: responseHeaders,
});
} else {
// this means that the middleware did handle the request.
// TODO: read from responseWrapper and send relevant response.
}
}
createSuperTokensRequestWrapper
and createNewSuperTokensResponse
would be similar to what you have already made, except that it would also do a mapping of input request paths with what the middleware expects. For example, for the refresh API, the middleware expects it to be a POST request to /auth/session/refresh
. So in the getMethod
function of the request wrapper, you could detect that if the actual request path is /auth/session/refresh
GET, return a POST instead, so that the middleware handles it.
About the // TODO: read from responseWrapper and send relevant response.
part, you would have to create mapping from responses written by the middleware to html / text responses that you want to send to the frontend. If the response contains a 401 status code without clearing the cookies, it means you want to navigate to the refresh route, else to the login page..
So essentially, you would end up reusing all the middleware logic making the overall code easier.
If this kind of makes sense, I can attempt to try this method out by forking your repo. If there is fundamental issue with this (im not too familiar with remix), lmk ๐ITEnthusiasm
01/13/2023, 2:23 PMserver.js
file handles the error cases for getSession
, I think. (You can look at the deriveSession
and setupRemixContext
functions to verify.) The server.js
file is the entry point for the entire Remix app, so any session errors that would have required redirects would already have been caught before I attempt to call my custom logout and refresh functions. Was that the only concern in terms of functionality? Does everything else seem to be working?SuperTokensHelpers.signin
). And in reality, these helper functions are pretty small and simple. Oftentimes, developers will make small, simple functions in order to handle interactions with their databases; this is to be expected for SSR frameworks/apps. With something as important as authentication, it's not surprising (nor is it inconvenient) for developers to also write a small amount of code to make sure auth is working correctly. And it's more flexible for developers to do this in their framework's way than it is to try to push it into their middleware (if their framework even allows that).supertokens-node
could be refactored such that the request
and the response
are not interacted with (nor required) directly. Instead of interacting with `req`/`res`, the functions/methods would take in cookie data and return response headers + response cookies. If that happened, then in my codebase, the SuperTokensData.Input
and SuperTokensData.Output
classes would go away. And I (as well as all other developers) would only need to work with SuperTokensHelpers
in a single file. (In fact, the helpers could be inlined directly in the server `action`s if desired.) This seems to provide a simple-but-flexible approach for developers -- whether they use an SSR framework or Express
. And from the looks of what I have, the refactors would really only be needed for `Session`'s methods (getSession
, createSession
, etc.).handleRequest
function would get passed to an Express Middleware. This is entry.server.tsx
, which is different.
**Edit**: The snippet doesn't work. ๐ฌ
supertokens-node
goes, one of the best solutions I think is an update to Session
. Otherwise, the code would still be a bit confusing, and supertokens-node
would have to create custom wrappers for every single SSR framework -- which is impractical.handleRequest
in Remix
is only for server rendering; it doesn't interact at all with the `loader`s, `action`s, etc. And it's the `action`s and `loader`s that specifically need to be called during login, logout, refresh, etc. Moreover, handleDataRequest
(separate from handleRequest
) only allows us to interact with the result of a loader
or `action`; it won't override any logic for us. (This, of course, makes sense because if there's any action-related logic, it should simply be placed directly in the action.) So we cannot reuse middleware()
anyway. The other SSR frameworks (Svelte Kit, SolidStart, etc.) will run into a similar issue. I really don't think there's a way around updating `Session`'s methods if there's a desire to support all popular frameworks in a flexible, reliable way.rp
01/14/2023, 5:36 AMSuperTokensHelpers.logout
function - how will errors from getSession be caught from this function? Also, if you are already doing session verification in server.js, why also do it in SuperTokensHelpers.logout?
The getSession in server.js in deriveSession
should probably pass in the sessionRequired option as false
. This will prevent it from throwing an unauthorised error and return undefined
instead of the session object. If it returns undefined
, the value of res.locals
would be res.locals = { user: { id: undefined } };
.
Why are we doing getLoadContext: () => ({ ...res.locals }),
in the createRequestHandler
function call if we are not consuming it anywhere? Maybe I just can't find where it is being consumed?
-----------------
About not using the middleware, Im really not sure if thats the best approach from SuperTokens point of view cause whilst for simple use cases, expecting devs to write the API logic themselves using the helper functions works. But when we add multi tenancy, account linking etc to the mix, it suddenly get's really complex.
Let me ask you this - If the APIs exposed via the supertokens middleware were exposed via the supertokens core itself (similar to other auth services), how would those APIs be called from the remix frontend? Cause technically, you could use the supertokens middleware in server.js (as a regular express middleware), and then from remix's point of view, it would just be APIs exposed by some auth service (that happens to have the same domain) which it needs to call.npm i -d
npm run dev
Got the following error: https://gist.github.com/rishabhpoddar/bfce3750a10fd373562d5e137c861d24ITEnthusiasm
01/14/2023, 3:23 PMserver.js
file handles the authentication piece, I was hoping that any errors would be caught? But I figured you guys would know for sure.
> Also, if you are already doing session verification in server.js, why also do it in SuperTokensHelpers.logout?
I need something that will allow me to revoke the current session and get response cookies to send back to the browser. That was the only approach I was aware of. Same for the token refresh.
> The getSession in server.js in deriveSession should probably pass in the sessionRequired option as false
For some reason, I still seemed to be getting errors even when I made sessionRequired
false, so I didn't bother. Maybe I can try again?
> Why are we doing getLoadContext: () => ({ ...res.locals }), in the createRequestHandler function call if we are not consuming it anywhere?
getLoadContext
is what sets the context
object that's passed to all of Remix's server functions (i.e., loaders
, actions
, etc.). The server.js
file doesn't do anything with `res.locals`; Remix does.README.md
file includes information about how to get the application started, as well as other potentially useful details. In order for the app to work, you first have to compile the SCSS files to CSS using npm run sass
. (You don't have to keep the sass compiler running if you don't want to.)
After that, the configuration variables need to be set properly through the .env
file. (The variable names can also be found in the README.md
file.)main
branch). But that implementation breaks when using HTTPS, so it is no longer valid. Even if middleware worked here, it would not be guaranteed to work for Svelte Kit
or SolidStart
.
I suppose that theoretically, the Remix application would be able to work if it called SuperTokens core directly. We can't call http://localhost:3000
when the server is HTTPS-only (this is a completely valid use case). And we can't call https://localhost:3000
because it's impossible to make secure, valid certificates for localhost. (Using something like mkcert
in prod would be an unnecessary, dangerous, and hacky solution.) We shouldn't (and sometimes can't) call https://MYDOMAIN.com
because it creates an unnecessary round trip that hurts user experience (waiting time). For highly active applications, this is impractical. (It's also just hacky.) We can call http://localhost:3567
because it is not an HTTPS-only server and does not require round trips. So that's good. However, taking this approach would require developers to learn the core API. And that seems a lot more complicated than just using an updating version of Session
.supertokens-node
. But to me, the solution to this problem is pretty simple: Improve the APIs to simplify the developer experience.
Just like I'm doing the on the experimental branch of my Remix app, supertokens-node
could expose helper functions for the more complex use cases. And these helper functions can still accept the input headers/cookies as a Map
and return the response headers and cookies as separate `Map`s (as shown on the branch).
And as long as the documentation was kept crystal clear, and the supertokens-node
helper functions simplified and accomplished as much as they could without abstracting too much away (e.g., without requiring req
, res
objects), the developer experience would still be good.supertokens-node
to be able to push into these frameworks with the advantage of flexibility. But it's going to be harder to do this if supertokens-node
goes against the flow of what these SSR frameworks are trying to do (and what they require, allow, and ban). Long term, I'm not saying that supertokens-node
needs to throw away middleware. But I am saying that the core pieces of SuperTokens (e.g., the Session
class) shouldn't assume that they're in a middleware-like context. If they do, the userbase will be limited, and SuperTokens will run into these incompatibility issues. And if for any reason another competitor arises that is more compatible (or an existing competitor catches on and changes their approach), then SuperTokens will be at a disadvantage.rp
01/14/2023, 4:34 PMITEnthusiasm
01/14/2023, 4:43 PMBaseResponse
). That's just a random separate comment though. I'm not saying that's a crazy priority or anything.
But as long as there's a way to push forward without requiring middleware, I think that would be huge so thanks. ๐๐ฟrp
01/14/2023, 4:44 PMITEnthusiasm
01/14/2023, 4:47 PMts
const remixApp = express();
const superTokens = express();
remixApp.listen(443);
superTokens.listen(3458);
But that still doesn't guarantee anything for Svelte Kit or SolidStart -- or other future frameworks.rp
01/14/2023, 4:48 PMITEnthusiasm
01/14/2023, 4:49 PMlocalhost
. So when someone attempts fetch(https://localhost:443)
(etc.), the request fails because Node.js doesn't trust the server (even though it's calling itself).rp
01/14/2023, 4:51 PMITEnthusiasm
01/14/2023, 4:51 PMhttp
is banned on https-only servers.rp
01/14/2023, 4:52 PMITEnthusiasm
01/14/2023, 4:54 PM443
and has some higher security configurations through its integration with Cloudflare.rp
01/14/2023, 4:54 PMITEnthusiasm
01/14/2023, 4:57 PMserver.js
file and attached SuperTokens middleware to that, then I could make that an http server. Then the problem goes away -- as far as my own project is concerned.
But that won't be a valid solution for people who aren't using the Node Adapter for Remix. And it's not reliable for other SSR frameworks.rp
01/14/2023, 4:59 PMITEnthusiasm
01/14/2023, 5:00 PMrp
01/14/2023, 5:00 PMITEnthusiasm
01/14/2023, 5:01 PMrp
01/14/2023, 5:02 PMITEnthusiasm
01/14/2023, 5:06 PMremix-supertokens
repo. (I'd like to add other kinds of examples to it but I just haven't had the time.)main
after tagging what I currently have on there. Then I'll update and push svelte-kit-supertokens
and solid-start-supertokens
rp
01/14/2023, 5:08 PMITEnthusiasm
01/14/2023, 5:10 PMrp
01/14/2023, 5:10 PMITEnthusiasm
01/14/2023, 5:12 PMapp
directory. When someone sees a /login
route and a /reset-password
route, they're probably going to be thinking, "Where are /logout.tsx
and /refresh.tsx
?" And there will be cognitive overhead with that. So I was trying to circumvent that as far as the remix-supertokens
example is concerned.
People in these SSR frameworks are trained to put as much into the "app" (main project) directory as possible for ease of use.rp
01/14/2023, 5:14 PMITEnthusiasm
01/14/2023, 5:34 PMrp
01/14/2023, 5:46 PMITEnthusiasm
01/18/2023, 8:58 PMnpm install > npm run dev
. Simpler startup than the Remix app. Still needs a custom .env
file though.
https://github.com/ITenthusiasm/svelte-kit-supertokensSolidStart
still has some server bugs to iron out. So I haven't been able to make any additional progress there. ๐ I really wanna use SolidStart
, though. I would translate my other project from Remix to SolidStart if it was an option.rp
01/19/2023, 5:11 AMITEnthusiasm
02/08/2023, 4:54 PMrp
02/08/2023, 7:58 PMITEnthusiasm
02/08/2023, 9:55 PMcreateNewSession
now requires a request object in order to function correctly. (This seems to be old news now. ๐
)
- https://github.com/supertokens/supertokens-node/blob/master/CHANGELOG.md#1300---2023-02-01
- https://github.com/ITenthusiasm/svelte-kit-supertokens/issues/1
This adds slightly extra effort for SvelteKit, Remix, etc., as now I need to update the example repos. ๐
Does anything in particular need to be tacked onto this request object for the session creation to work correctly? Or would a random request object without any meaningful information be sufficient?
I was hoping things would move more towards data-in/data-out than req-res-in/req-res-out. Was there a motivation for this change?rp
04/13/2023, 12:38 PMITEnthusiasm
04/13/2023, 12:42 PMrp
04/13/2023, 12:42 PM