Better Docs
sergiodxa opened this issue · comments
- Documentation website
- Document how to approach a Passport to Remix Auth migration
- Document all current strategies
- Create example apps for every strategy
- Create examples using Cloudflare Workers
I just saw this and wanted to let you know that I would be very happy to help, if that would be useful.
Maybe you can use ChatGPT to generate that! 😄
hi @sergiodxa
thanks for creating this awesome package, me and my team have used it in production many times 👍🏼.
I would love to contribute and work on a new documentation website. Can i create a PR?
P.S: Seems like the CONTRIBUTING.md file is a bit outdated(https://remix-run.web.app/dashboard shows a 404)
🙏 please 🙂
Seems like a lot of goodness packed in here, but I'm left scratching my head in many cases.
It's still not clear to me what I'm supposed to use the second arg to the oauth2 strategy constructor (StrategyVerifyCallback). I guess I can fetch additional user info there using the tokens it is called with and commit the result to a session. But why is it called "verify"?
I didn't even know there was an "authorizer" part of this package until I poked around in the source. How do I use that? Where are rules configured?
Why is the session id field blank?
It may be another issue - but what if I want to store separate cookies for each token and the user info in cases where that information won't fit in just one?
I didn't even know there was an "authorizer" part of this package until I poked around in the source. How do I use that? Where are rules configured?
The authorized is undocumented on purpose, it's not considered stable
Why is the session id field blank?
I'm not sure what you mean by this, but the session ID is generated by the session storage object, not by Remix Auth, I think if you use createCookieSessionStorage there's no session ID, but that's an implementation detail that belongs to Remix.
It's still not clear to me what I'm supposed to use the second arg to the oauth2 strategy constructor (StrategyVerifyCallback). I guess I can fetch additional user info there using the tokens it is called with and commit the result to a session. But why is it called "verify"?
The name came from Passport, the idea is that you use what the strategy gives you (form strategy gives your a formData but OAuth2 based ones gives you more things) and then verify if the user exists in your app, e.g. query your DB, if you don't need to do this you can just return what the strategy gives you.
what if I want to store separate cookies for each token and the user info in cases where that information won't fit in just one?
This is outside the scope of Remix Auth, you can remove the successRedirect when calling authenticate and then get the return value from the strategy and do whatever you want with that data, but if you don't set the user data in the session you won't be able to use the isAuthenticated method.
It's still not clear to me what I'm supposed to use the second arg to the oauth2 strategy constructor (StrategyVerifyCallback). I guess I can fetch additional user info there using the tokens it is called with and commit the result to a session. But why is it called "verify"?
The name came from Passport, the idea is that you use what the strategy gives you (form strategy gives your a formData but OAuth2 based ones gives you more things) and then verify if the user exists in your app, e.g. query your DB, if you don't need to do this you can just return what the strategy gives you.
Got it. In my case I'm hitting my aws cognito authorization endpoint. I get back tokens (id, access, refresh) but no user information. In the verify callback I'm able to hit another cognito endpoint for that. I guess there may be a payload in the id token if I decode it instead of making this extra call.
Thanks for the clarity 🙂
Why is the session id field blank?
I'm not sure what you mean by this, but the session ID is generated by the session storage object, not by Remix Auth, I think if you use createCookieSessionStorage there's no session ID, but that's an implementation detail that belongs to Remix.
Thanks. I was comparing what I was returning from the verify function to the result of sessionStorage.getSession and noticed there was a bit of extra meta on the session. Couldn't tell where it was coming from since remix-auth was calling sessionStorage.commitSession on my behalf.