Router : Entry points not valid on refresh about reef

[cferdinandi]

As a rule of thumb, never store sensitive info (like usernames or passwords) in the client at all.

With JS-driven apps, you generally want to pass the username/password to the server at login only. The server sends back a session token (which you can save in the client). You use that token for all future validations for the duration of the session.

This is what flows using OAuth, JWTs, and so on do.

[cferdinandi]

Ohh, good call. I need to update the docs on this. You'll need to update your server to point all files back to your index.html file, and that will vary by hosting environment.

I'll post some docs on that soon.

[k5nn]

So if I'm reading this correctly I have to adjust the way how the server handles routes to do this right?...

[cferdinandi]

That's correct, and is true of all SPA's that use "real" URLs for their routes.

Here's an .htaccess file example for apache servers.

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteRule ^index\.html$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule . /reef/demos/router/index.html [L]
</IfModule>

And here's what it might look like in express (taken from the Reach Router docs):

const path = require("path")
const express = require("express")
const app = new express()

// requests for static files in the "public" directory
// like JavaScript, CSS, images will be served
app.use(express.static("public"))

// Every other request will send the index.html file that
// contains your application
app.use("*", function(req, resp) {
  resp.sendFile("/public/index.html")
})

app.listen("8000")

This article gets into more details.

[ThatTonybo]

Butting in for a minute, say you want to protect a route (ie. prevent /admin access only to users logged in. Would you build the auth checks and sessions, etc for keeping track of the user on the server side, then just build the front end and router normally in the index file?

[k5nn]

I'd do it on the client side

When the user logs in the response would return a user type in the response then create a store for that for easy access and then do the user type referencing in the render event if you want it to be persistent for that session or you're using the traditional CRUD method then check out the sessions API

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/sessions

[ThatTonybo]

Sounds a bit insecure though, having authorization code and such on the front end that could be seen or possibly edited easily?

[cferdinandi]

Depends on how session state is managed. If it's a single-use token that expires after a short period of time (ex. an OAuth token), the risk is low, and not really all that different from server-managed states with hashed cookie IDs.

[ThatTonybo]

I guess that does make sense. Would it theoretically be possible to pass work like validating passwords through to the server though?

[cferdinandi]

The docs have been updated with info on server configurations.