> But what should I say? If it's not a real human then I can just return an Internal Server Error, but if it's a person suffering a malfunctioning server or network then i want to give a polite message. and what would be the right thing to say?
This is a good question. State mismatch happens more often than I intuitively expected, so you should handle it gracefully. I give an error message along the lines of “Something went wrong when signing in, please try again” and then a link which starts the whole OAuth flow over again. — Theron > On May 30, 2019, at 10:52 PM, Mike Orr <[email protected]> wrote: > > On Thu, May 30, 2019 at 6:25 PM Jonathan Vanasco <[email protected]> > wrote: >> >> Many of the things you mentioned are specific to Keycloak. I can't answer >> those. >> >> I can take a deeper look at the oauth details tomorrow. the following are >> things that just popped at me. >> >> On Thursday, May 30, 2019 at 8:57:28 PM UTC-4, Mike Orr wrote: >>> >>> - What should I do if there's a state mismatch? I don't want to give >>> >>> the user an Internal Server Error, or tell them they're bad when >>> there's nothing they can do about it. >> >> >> If there is a state mismatch, something very bad happened and you should not >> let them login. > > But what should I say? If it's not a real human then I can just return > an Internal Server Error, but if it's a person suffering a > malfunctioning server or network then i want to give a polite message. > and what would be the right thing to say? > >>> - What should I do with the token? >>> - Should I save the token in the session? >> >> >> Are they using oAuth to login to your app every time? If so, you should >> save it in the database. If they will authorize via oAuth every time they >> use the app, you could store it in the session or trash it. > > They'll authorize at the beginning of the Pyramid session, or if the > session expires, or if they quit the browser and restart it. It sounds > like I can store the userinfo data in the session and then I don't > need the token. > >> When a user approves your app, the server gives you two secret tokens. >> You use the access token to make all your requests to the server. That is >> likely saved in the database and the user's session. Think of it as a >> "session_id" for the upstream api. > > I don't need a session ID for the upstream API. There are no remote > resources to access. > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/pylons-discuss/CAH9f%3DurU8AmtiHsYE_boOGkk2oeQ__nHEJQS88CKBhNuUYGNbQ%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/4EEC40E9-53AE-483D-8BA3-118995F71362%40luhn.com. For more options, visit https://groups.google.com/d/optout.
