Auth0 Automatically Authenticates (Day 117)
May 13, 2022•496 words
Total hours: 235.583
Top three:
1) Planning the authentication login setup
Not much to really discuss here in this vein. BUT I GOT ITTTTT!!!
2) Got Fly deploy working correctly!!!
Okay so there are ARGS and ENV. ARGS are only used during the build process and ENV’s are used during the run process. What this means is that these must be passed into the Flyctl command like so.
Also the docker file is modified to have ARG . This signals to Docker that if it can’t find this during build to raise an error.
This is nice because there is redundant protection. If it’s forgotten Docker will catch it and Mix will also throw an error.
The command is flyctl deploy --build-arg <some arg> --build-arg <some arg>
The only downside that I see with fly.io is currently a minor one but will grow into a major one in no time. It’s DATABASE migration. The database is migrated, THEN checked to see if everything is working correctly. If not it’s rolled back and the DATABASE ISN’T. This can lead the database in a very bad and inconsistent state. This means that this CANNOT be allowed to happen under any circumstances WHATSOEVER.
This is another reason to have the three stage build process.
3) Discovering map for conceptional logout
So if you go to mygaya.day now it’s possible to login. However logging out isn’t possible yet. If you delete the cookie you’ve deleted the session linking it to Gaya’s web server. However you haven’t deleted the session to Auth0’s web server. Meaning that when it goes thru the authentication process it automatically logs you in w/o giving you an option to actually sign in with an different account.
This is because using a social or third party login provider is complicated in it’s own right (even without Auth0 involved). This is because often the operator wants to logout of an account tied to a service without actually logging out of the account. For example logging out of Instagram (if you signed in via Facebook), without logging out of Facebook.
This is further compounded when dealing with Auth0. Since there is state possibly maintained at three levels. Your server, Auth0’s servers and the social provider’s server.
Stage one logout is just logging out of your own servers but not logging out of Auth0’s servers. This is what mygaya currently does.
Stage two logout is logging out of your own servers and logging out of Auth0’s servers. This is what is commonly expected by operators.
Stage three logout is logging out of the whole chain. Your own servers, Auth0’s servers and the social provider. Secure and would make sense most in a public computer concept. (Whose gonna really remember who doesn’t have a deep understanding of this architecture, that if you signin w/ Google on a public computer into MyGaya. That when you sign out you’ll also need to sign out of Google as well???)