"Requires login" prompt?

[tomkersten]

When going to a "protected page" on a client application, you generally want to forward the person to the login page with a message to the effect of "You must sign in to see this content."

Any ideas on how we can accomplish this with the anvil-connect server?

[christiansmith]

@tomkersten perhaps depends on how you've set display in the options for Anvil.configure().

With the default value ("page"), you could store the path to the page in localStorage while the user is sent to your provider to authenticate by calling Anvil.authorize(), and have the app 1). route the user to that path when it bootstraps and 2). then clear that target route from localStorage.

With display configured to "popup", you could invoke Anvil.authorize() by resolving the Anvil.session value in the $routeProvider definition. Because Anvil.authorize() returns a promise, you could pass success and failure callbacks to then() which would either complete the navigation or display some "Unauthorized/Forbidden" message depending on the response from Anvil Connect.

[tomkersten]

I think I may have expressed myself poorly...

I have implemented the "return to where you left off" functionality and it is working as you describe.

However, what I'm referring to is that when you are redirected to the AC server, it'd be nice to inform the user why they are there, instead of just landing them on the login page. In other words, somewhere "near" the login form, have a "flash" message, or something that says "you must log in to view this content"...or something to that effect.

Make sense?

[christiansmith]

Good idea. I'll put some thought into it.

[christiansmith]

@tomkersten I'm looking through the OpenID Connect specs and I don't see anything indicating a standard way to pass this kind of message along.

Without adding a non-standard feature like this to the auth server, you could solve the problem on the client side by making your own ui prompt indicating login is required and displaying an app-specific message. If the user is signing in via third party, you could skip the signin view on the auth server by displaying options that link directly to the /connect/:provider endpoint. In this case, assuming the client is trusted, it should appear to the user as if they went straight to Google and back. To my understanding, OIDC doesn't officially support the OAuth 2.0 password grant, so you'd still have to provide a link to the auth server if the user wants password signin.

There are definitely pros and cons to this approach. I'm not opposed to supporting an additional authorization parameter, but I'd like to know if we can achieve a satisfactory experience in practice without it.

Please let me know what you think.

[tomkersten]

Hmm.

I'm not sure right now. This isn't a huge thing at the moment, because we aren't exposing the service to a broad range of people. A client-application could do this, but it would likely degrade the overall experience, as far as I can tell. However, for now, let's close the issue, try to address it purely on client-side as you state, and see how it goes. If things bubble up, we'll talk more then.