Echo JS 0.11.0


tracker1 comments

tracker1 49 days ago. link 2 points
Advertorial content, not necessarily off topic, or out of line, just not generally appreciated.

I'm also not sure I quite understand where Bit fits into the scheme of things, it seems to be an additional repository system to manage on top of whatever CI/CD you already have not to mention npm, builds, releases, etc.  I'm not sure how many environments can realistically utilize the platform and if it's worth the additional complexity over npm enterprise or another internal repository system.
tracker1 50 days ago. link 3 points
I so want to use this for "unexpected" error conditions, capture the background on a canvas, clear it all with the image of the background, and every time you close the dialog it repaints in a different position like old-school windows 9x and 3.x used to.
tracker1 57 days ago. link 1 point
This is why you should use a normalization before serializing and doing any comparisons, unless relying on the order.
tracker1 57 days ago. link 1 point
That's probably fair, but should note it, just in case...  It's surprising how many apps today still need to support IE9-11.   Which is a shame.
tracker1 59 days ago. link 1 point
Definitely interesting... not sure I like the store/state management piece, but it's definitely interesting.

One thing that would be nice to see would be browser support.  I'm assuming the store is using proxies in order to raise state change events.
tracker1 62 days ago. link 1 point
TFA says you should keep the tokens in the database, and fuck with the expires date... a revokation list is *FAR* lighter.
tracker1 63 days ago. link 2 points
While mostly useful, I do have a few criticisms...

1) there's an exp (expires) attribute already, you can use short lived (5 minutes) and/or refresh tokens for automated systems, and slightly longer for use with an SPA client.

2) regarding revocation, have a key/value store that keeps a revocation list, and have those items auto-expire when the token expires to keep that collection lean.  Redis is a great use case for this.  Do *NOT* fiddle with a server-side duplication of tokens generated as the article indicates.

3) cache decoded tokens and secondary lookups.  For example, in a system I am working on a token will indicate an affiliation and roles associated for that use.  This gets flushed out with some additional data from the DB that's used through the server-side.  While this can be fetched at any time, a good caching strategy is helpful here.

4) client-storage, generally the token is sent on the querystring/url, best to store in an incapsulated variable (as suggested), but also to immediately do a client-side URL replace.  

    export const clearAuthorizationQuery = _ => {
      const { search, pathname } = window.location;
      const query = qs.parse(search.substr(1));
      delete query.authorization;
      let q = qs.stringify(query);
      if (q) q = `?${q}`;
      window.history.replaceState({}, 'hide-authorization', `${pathname}${q}`);

continued, if you aren't running potentially untrusted code, you can use localStorage to stow your token, combined with short lived keys and a refresh token, you limit your exposure risk.  There are other considerations if your front end is a static delivery site... since you cannot inject the token for authentication when doing so.  You *could* do this at your API layer, and support either a cookie, or the Authentication header.


There are other considerations, and this topic (authorization/authentication/security) could cover an entire book.
tracker1 63 days ago. link 1 point
Though a bit OT for this site, it's a really nice start to what appears to be a series of articles.  Well written, though a bit more short than I'd like for this topic.  Looking forward to the followup.
tracker1 63 days ago. link 1 point
Nice tips for dealing with styled-components.  I've been digging react-jss more myself, but it's another interesting approach.  I could also see styled-components working better if you're more content heavy then it's probably a better approach vs. more of an application.