Switch framework default authentication to cookies/sessions instead of basic auth about frame HOT 6 CLOSED

Adding to the wiki has generally been your stance, I for one am good with that and think its the best approach. You know how us devs are though, we'd rather be writing code than wiki entries.

I'll get a post up for hapi-auth-jwt2

from frame.

One left field solution would be for this to be including in the on-boarding that occurs with first-time-setup.js which could ask the developer which authentication method they want and to configure that automatically at setup, that'd be interesting.

True, it would be a nice convenience. I'm just not interested in adding that kind of maintenance overhead. The templates would need to live somewhere, then we'd need to have logic to modify code files based on their choice, oh and don't forget doing this for tests too. 😬

And then we'd need to figure out how to get the live demo to run without doing some kind of environment detection and custom build or something.

Personally, that's doesn't sound like a good return on the time investment.

Thanks again to everyone who's interested in these projects and big thanks to everyone for getting involved and contributing. ❤️

@fishmongr I'm not sure what you meant by "Outside of being a documentation ______". I edited your comment and I'm not interested in that language. If I'm mistaken or if was a typo, that's cool, but let's just leave it at that for now.

from frame.

Thanks! So my stance on cookie based authentication... given we're in a new age of SPAs (Angular, Vue, React), decoupled APIs, mobile devices, IoT, and general decoupling from the front and back ends... cookie auth is now in the days of the past. More and more services are deprecating cookie-based auth in favor of basic authentication with API tokens, JWT, and OAuth as they're stateless. Rather than go into all the reasons one should avoid cookie-auth nowadays, Auth0 has a great read here:

https://auth0.com/blog/cookies-vs-tokens-definitive-guide/

In my strong opinion, this repo should have started with JWT, but this isn't my project. :) Moreover @jedireza 's stance over the year (years?) has been to keep this project as a bare-bones starter. The reason I'm just contributing now is because this starter has helped immensely over time, so I owe you a few PRs. :) But @jedireza, a reason for not committing moving forward is that I know you don't want to progress this in terms of features. If you're interested in having more people contribute to this, throw out some ideas on direction and lets keep this project alive! Especially now that you've done the work of a Hapi 17 up.

In my opinion, implementing cookie auth is like going back in time. But you know how opinions go nowadays.

@fishmongr happy to see you stepping up on the docs. Swagger is an amazing step in the right direction.

from frame.

Thank you both for starting a good conversation around this.

My small personal projects are hosted on Heroku and I'd most likely add cookie/session support because the experience of detecting a missing session on a deep URL (a-la Aqua) and redirecting to the login screen offers a better user experience. For example, if I'm logged out and hit http://getaqua.herokuapp.com/admin/users, the missing session is detected on the initial request and the user is redirected immediately. If I was using client-side only authentication, the page would load then we'd need to detect a missing session on the client and then redirect... resulting in a flickering experience for the end user.

On the other hand, if your system isn't coupled with the front-end experience this way or you don't mind the possible flicker-y experience, a non-cookie/session approach may work out fine for you. Or maybe there's a way of cleaning up the user experience where this is a non-issue.

I'm sure there are a dozen other nuanced scenarios which require us to inject opinions, which I wanted to avoid to keep the project simple. In the same vein of trying to stay opinion-free (as much as possible), one needs to ask, which JWT library should we use? I'd rather leave these choices up to app developers. This is primarily why I went with basic auth. Plus the hapi-auth-basic module is maintained by the hapi core team. Which is a pretty neutral position in my opinion. 😁

I think we could accomplish a better on boarding experience with Frame by creating guides (with copy/paste snippets ideally) in the wiki for adding cookie/session auth, JWT or others. Then linking to those in the README.

from frame.

Thanks, good feedback @bmgdev and @jedireza!

I think updating Wiki guides on implementation scenarios would certainly be helpful. One left field solution would be for this to be including in the on-boarding that occurs with first-time-setup.js which could ask the developer which authentication method they want and to configure that automatically at setup, that'd be interesting.

Re: Updating the swagger docs, it was a good way for me to get my head around the project, happy to continue to contribute where I can. Hapi-Swagger definitely has it's limitations still being on Swagger 2 but even Swagger 3 / OpenAPI Spec 3.0's Swagger UI is still lacking in some design and usability features for full-scale docs but it certainly can be indispensable for projects like this.

Lately I've been focused on replacing Swagger UI in my personal projects with ReDoc which is still completely powered by Swagger.json but replaces that dated limited accordion view with the now industry ubiquitous 3 panel API reference layout. https://github.com/Rebilly/ReDoc
Docker's API is actually using it: https://docs.docker.com/engine/api/v1.25/#

Outside of being a documentation [redacted] it provides markdown format to add all the typical sections of content you might want to include in documentation though Github Wiki is certainly a more standard approach.

from frame.

... we'd rather be writing code than wiki entries.

Let's make sure to put some code snippets in the wiki entries 😅

I'll get a post up for hapi-auth-jwt2

Rad! 🙏

from frame.