Do you react to your expression, or express your reaction? Normally, I think we all express our reactions. Maybe those are the same thing, but the reaction seems to come first. It seems we need to react, then express it.
In coding in React, while using Express in the same app, you can do it either way. If you have a server side rendering, then you Express first, then React. My app is doing client side rendering, with API calls to the backed in Express. So React first, then Express.
In setting up routes for certain pages, it's cumbersome to not be able to simply go to Express for a certain route I wanted to go to. First I had to deal with a request ion React, then go to Express through React. It would have been convenient if I could easily choose when I wanted React or Express to deal with a route. But I can't :/
With SteemConnect, you need a redirectURL sent in order for your JWT access token to be received. You can choose any route, say for example, /auth, or /complete, or /success. So the URL is something like http://example.com/success.
I wanted to receive that in Express to create a CSRF token there directly after a login, rather than go through React first. But I can't. So I needed to make a React component for the SteemConnect authentication success, then make an API call to the Express backend, which will process the data like the expiration of the token, username, create a CSRF token, add data to the database, and then return the CSRF token and SteemConnect JWT for a successful authentication in React.
The SteemConnect token only has your username, expiration, and other data encoded (not encrypted). But it can be used to re-authenticate you until it expires. I won't be holding that token in the database, don't worry. You SteemConnect credentials will only be in a Cookie ~that you can eat~ that is stored in your browser.
That way, the next time you visit, you won't need to login again and again. I notice SteemPeak is setup that way. I don't like the hassle. I plan to add an option later to customize the login: do you want the token to last just 1 week, 1 month, or auto renew and auto-login; or do you want to have to login each time you visit after closing the page (like SteemPeak).
Your SteemConnect token will be safe. It won't be accessible to the front-end JavaScript, as I will be setting HttpOnly on the cookie, meaning it can only be sent through HTTP requests. If ever (by some freak accident on my part) an XSS vulnerability slips in happens, my site may be in shit, but at least your cookies won't be accessible by an attacker who tries to steal ;) I doubt it will come to that though.
As much as developers say XSS won't happen to them, it can. All it takes is a mistake. We may protect against it, but you never know, ya know? This way, your cookie will be safe on my site no matter what. Busy.org has your token in the browser cookie, without HttpOnly on. Again, it's only an issue if you have an XSS vulnerability where an attacker can use JavaScript on a site to access your cookies, and therefore your JWT token stored there (in non-HttpOnly mode). But I prefer to make your token doubly-safe.
Well that's my latest dev tale to share. I hope it made sense to most (some?) of you :)
Thank you for your time and attention. Peace.
If you appreciate and value the content, please consider: Upvoting, Sharing or Reblogging below.
me for more content to come!
My goal is to share knowledge, truth and moral understanding in order to help change the world for the better. If you appreciate and value what I do, please consider supporting me as a Steem Witness by voting for me at the bottom of the Witness page.
