Is there a recommended "Polymer way" to do user authentication?
This question includes both the technical pieces AND the UX.
A soup-to-nuts example (and/or tutorial) of a UX for doing user auth would be fantastic.
Note: The Polymer Starter Kit does not contain any authentication UX examples.
In this question...
"UX" means:
The COMPLETE "user-experience" involved in signing up for a new account, logging in and handling forgotten user id or password. For example, a typical landing page for a typical web app will usually have some buttons in the upper right corner for signing up for a new account and logging in. What happens when someone clicks those buttons and how to handle the entire flow would be a very useful example for Polymer developers given that functionality is necessary for most modern web apps. I would love to not have to create my own amateurish "home-brew" concoction from scratch for a solution but, instead, to have something relatively professional and generic I can "plug-n-play" into my app and modify only if/when necessary.
You need to build a custom element with all the relevant styles, templates and scripts to express the UX.
Related
I have an application with (nuxt js using nuxt-auth) with local authentication so far (later I want to add git and google auth).
Now I need to add authentication to invoke other services / API (like google cloud rest API, payment system, youtube API, etc...)
The question is: the user is authenticated only once (during login to the application.) but each of these 3rd party APIs has its own authentication.
How to implement multiple authentications. (I read the documentation and google for the entire day but there is no clear answer).
As of today, it looks like it is not doable (people are needed on this module): https://github.com/nuxt-community/auth-module/issues/889
So, you would need to make it manually by plugging the APIs yourself.
Answer to your latest question~comment
Nuxt is indeed nice with some of it's modules (but you can totally dislike it, no problem :D).
First thing that you need to know, is that this project (nuxt-auth) is not the biggest one, #pooya is doing his best but he is on a lot of projects, so he cannot give all of his love to it. Then, you also need to understand that it's working great but it's still in a decent beta state with a lot of missing features, needed documentation and a lot of small things to make it an all rounded solid top notch solution.
That do not mean that you should not use it, I'm just saying that this module do have some limitations. Hence, the fact that it is not supporting a whole lot of OAuth solutions in a clear + simple + flexible way. And some breaking changes may be introduced in future updates.
The module is aimed towards having an OAuth solution to block the content of your website behind it (in my opinion). It means that you will usually use a single login solution and then, being able to have access to your app. I don't think that it's a viable multi-OAuth solution (yet).
Some services don't even need to use a solution like this. Stripe for example, should not be handled on the frontend but communicate with a backend for sensitive variables and just send minimal info thanks to Stripe Elements.
That said, the most common solution is JWT or OAuth2, and you could totally have a backend service or service like Okta, Auth0 or alike, do the heavy lifting by allowing simple logins to providers (Github, Google etc...).
To sum up, you do connect to this backend/service thanks to nuxt-auth, the service itself does the provider connection and you get the best of both worlds while still connected in a secure way through your initial nuxt-auth entry point login.
Or you could try to reach the community on Discord, see if somebody knows how to do it. Or even try to read the source code to see if it is currently feasable.
And that's my 2cts.
I have started to work on a greenfield web project which will use ASPNET Core and Aurelia. I cannot find a definitive best-practice approach to structuring this on the client. My current thinking is that each app feature will be be a separate Aurelia application, i.e. when a visitor clicks on the link "Accounts" the browser will make a server request to https://example.com/accounts. This will return a single HTML page which bootstraps an Aurelia app just for accounts. All the accounts interaction will be delivered using Aurelia. Similarly, if the visitor then clicks on "Dashboard", another server roundtrip will bootstrap the "Dashboard" Aurelia app.
Is this a good way of approaching the problem? I have some concerns around application state - in that there will be cross-cutting concerns and data which I don't want to keep round-tripping to the server every time I need it, e.g. audit logs, user information.
I see that Aurelia has the concept of Features - semantically this is exactly what I want as each of these areas of the app will be delivered as a feature. However, I cannot find any good examples of the use of Aurelia features.
Any comments or experiences in similar projects most welcome.
I don't know if it's the 'best' way of doing it but a lot of the applications I build are user / admin type products.
Rather than building an application for each side I take advantage of child routers and structure my application with a page based convention as described here:
https://ilikekillnerds.com/2015/10/how-to-structure-an-aurelia-application/
Our Challenges:
It seems to me The Polymer 1.0 developer community faces the following challenges right now:
We have no user auth UX example to follow. This Stackoverflow question requests a user authentication UX example. And describes why it's needed. This Github issue also documents multiple user requests for such a user auth UX example. And there has also been lots of anecdotal chatter on the Polymer Slack Site about this issue as well.
Modals don't currently work inside <paper-drawer-panel>. This open bug issue report, this Stackoverflow question and its accepted answer collectively prove that a bug requires <paper-dialog modal> elements must go outside any <paper-drawer-panel> element in order for the modal to render properly (i.e., in front of the modal's backdrop, not behind it). This issue report and this Stackoverflow question also verify same.
But modals inside panels have become the defacto standard auth UX design. It seems to me a principle of modern web app design that user authentication buttons (e.g., login and signup) go inside the equivalent of whatever version or "analog" of <paper-drawer-panel> any given web app happens to use. (Also, these auth buttons usually appear in the upper right corner of every screen of the app until the user logs in. Then they are replaced with an icon or link indicating login status.)
Code Examples:
Refer to the code examples contained here (in the question and answer). That code would be the same for this question too.
Question:
How do we, the Polymer 1.0 development community, best meet these challenges and build the best user auth UX experience possible? Perhaps there is a mistake in my facts or assumptions stated above? Perhaps someone has a direct (or workaround) solution they can share? Perhaps someone from Google's Polymer team would like to chime in? Any and all ideas, suggestions, feedback and answers are welcome.
On this bug report rubenstolk provides a hack-fix as follows:
To implement #dhpollack's hack in a nice way, add this function to your custom element:
// https://github.com/PolymerElements/paper-dialog/issues/7
patchOverlay: function (e) {
if (e.target.withBackdrop) {
e.target.parentNode.insertBefore(e.target._backdrop, e.target);
}
},
And add on-iron-overlay-opened="patchOverlay" to all your <paper-dialog>'s
I have tested it and verifies that it works. So for now, that solves challenge #2 in the question. Therefore, I suppose it is sufficient for now to wait until the bug is fixed.
I modified the PSK adding a login form, made out of a paper header panel, modifying routes for unauthenticated users and hiding the toolbar, by default.
This is done with
document.getElementById('headerContainer').style.display='none';
document.getElementById('mainContainer').style.paddingTop=0;
The UI reappears with
document.getElementById('headerContainer').style.display='block';
document.getElementById('mainContainer').style.paddingTop=168px;
This is just the beginning of a solution. For a complete solution, I would like an iron auth element supporting generic host and usual OAuth sites.
I am new to rails, cucumber and rspec. To help learn all three, I've started building a realistic application that requires login.
I would appreciate a little guidance as to where to start and confirmation I am on the right path.
I started with 2 features files. However, I have stopped at this stage as I'm wondering whether the 'login' feature (although a core aspect of the app as they can't do anything without being logged in) should come after the other assets and models, such as the things they manage when they are logged in.
So, which would come first? Features for the login or features for the models they manage?
example feature files:
Feature: User loads application
As a user
I want be able to load the application
So that I can manage my files
Scenario: Load application
Given I am not yet using the application
When I visit the application
Then I should see "Welcome to app"
login feature file:
Feature: User logs in
As a user
I want be able to login
So that I can manage my private files
Scenario: Successful login
Given the user "Username" has an account
When they login
Then they should see "You have logged in successfully"
Should I have started with a feature that they will actually use as the point of the app?
The order in which you implement features is a business decision. Whether you start with the login process or another feature depends on the business value each feature carries.
To help you find out where to start, you'll need to ask questions to the stakeholders. Here are a few examples:
Could we build feature A without user authentication?
Do we absolutely need user authentication at this point?
Let's consider we have resources to build only one single feature, what would be the most valuable one right now: login or feature A?
Building feature A before authentication can be a good strategy, as you'll be able to expose the feature to test users and improve on it earlier. Or, it could make no sense at all on your specific project and you'd want authentication to be ready before anything else.
Now, to comment on your particular scenarios, the style your using is pretty good.
I have the feeling (I might be wron) the user loads application feature is not really useful though. As a user, do you care about a "welcome to app" message? This scenario looks like a pre-functional setup test, something you'd like to have as a developer to kick off the development process. But it does not seem (again I might be wrong) to tell anything useful about the behaviour of the application.
This could be encapsulated behind a Cucumber feature describing some real expected behaviour of your systm (like the login process or adding items to a cart or reading blog posts, whatever is relevant to your domain).
Twitter offers 'web intents' that are an alternative to OAuth access to their API. Basically, this provides a less feature rich experience, but can still be quite handy. User clicks on 3rd parts websites can create popup windows that check whether the user is logged in to twitter and if they are, allows them to us some Twitter features such as tweeting, retweeting, or following users.
My question is, how could I go about implementing an API like this? Are there tutorials or libraries? I'm not sure what technologie(s) power web intents or where I should start searching.
Thanks.
You can read more about web intents at webintents.org and read the W3C's draft spec. As far as I know, web intents are still somewhat of a new beast on the web and they have not been standardized.
Still, you may want to read this blog which contains a few examples of registering web intents and check out Paul Kinlan's git repo https://github.com/PaulKinlan/WebIntents
Hope that helps you get started.