Project status #670
Comments
|
I use Portier as the login system for https://www.pipes.digital/. Ran into an issue a while ago when logins did not work reliably, but that was related to the specific ruby gem I used (and wrote myself, forking the old browserid gem) that probably ran into some issues with browser compatibility and the Rack session cookie. Since the last fix there it has been completely calm on that front, and portier itself (including the broker of the project) just worked. For a side project portier is completely suited imho. |
|
Sign up worked reliably for me. A question: As far as I can see, portier supports only gmail addresses right now. Does it also support github authentication (or is it possible to integrate it somehow?) |
|
Portier supports all email addresses via sending a code to the email, the only thing special for gmail is there the oauth flow is activated and the user can login directly instead. Which admittedly makes the login with gmail quite a bit nicer, so maybe that's what you meant :) For github integration the project always ran into the conceptual problem that the user login has to be an email, mapping that to github was never solved. Same issue for all other login systems where the email is not the user id. What could be integrated is oauth login with other email providers, back then that just did not work reliably with anything but Gmail. But fastmail for example should work now, so portier could likely be extended there. |
|
So if I understand portier correctly, it is responsible for just identity management, i.e. asserting that a user is who they say they are. Once the user's identity is verified, it is still up to the application on how to actually store the user's data. So it is quite different from authentication providers (like https://github.com/teamhanko/hanko) in the regard that it makes no assumptions on how the user's data is stored. Please correct me if I am wrong anywhere. |
|
No, that's completely right. The portier broker sends the user back with a certification (jwt token) that the user really controls the email he entered into the login form. Everything else (like how to store that email) is up to the application. |
@IgnisDa though late to the conversation, we have a public facing services backed by Portier for authentication. The first is a CLI based license self-service tool and the latter is the evangelism part of the company where I have fronted it to our JupyterHub deployment; though I had to fork OAuthenticator to support OIDC. Currently we are working on replacing our downloads portal that will also be fronted by Portier. I put together the GCP deployment guide as a result of the learnings of this work. So from our perspective, this already is "production" ready and we have been using it as such for nearly two years. As hinted elsewhere, you will need to maintain sessions yourself, so typically you have Portier validate the users email address but then you serve them a token (eg. cookie) to main the browser to avoid juggling a custom token; though for a CLI tool you typically do not use cookies, though could could there too. Having used AWS Cognito and other cloud based IDMs, Portier provides the best user experience. The user regains some privacy (not having to use an OAuth2 provider tracking them) and it has you rework your service I think for the better where everyone has an account including those that never signed up[1], but what is important is what they are authorized to do, so you forces you as a developer (and product builder) to focus on the more important aspect of handling users. As a developer, you get to interact with it using standard OIDC libraries or it is not difficult to roll your own. One word of warning, which applies to all IDMs that send emails to log in, you may want to carefully consider the 'click link to log in' functionality. We ran into usability problems which particularly for our JupyterHub environment were impossible to solve with documentation/teaching/hand-holding. Some users may use one web browser (or have the tab to your service in an incognito window) whilst the link is opened in another browsing context (eg. another browser). One workaround is to muffle a security feature whilst another is to force the user to type in the code and to remove the link from the email template; your mileage may vary depending on how you like your UX to be. Portier unfortunately does makes the UX a little caustic as it takes a 'firm approach' to incorrect logins. If the user types in the wrong code or uses the link in the wrong browsing context, the login attempt is aborted and deleted. The result is the user is now unable to go back and remove the typo from the code or re-try the URL in the correct browsing context and nothing will work. They then retry the login, but they risk being throttled if they retry too many times. I think my only other complaint is that it is written in Rust. This unfortunately makes contributing really difficult for those (like myself) where you first need to learn Rust which I suspect applies to the majority of Portier's userbase. Maybe one day I'll take a stab at fixing the UX problem described above but I too have side projects I need to look at. :) That said, and as mentioned earlier, Portier is a really useful and important part of the projects I work on. Whenever an authentication piece is needed, I do find myself figuring out if Portier can be made to work for the use case. It usually does. [1] remember to consider disposable email addresses and plus addressing (as well as '.' in a Gmail is ignored) |
|
Thank you for the detailed rundown. I will consider Portier for the next project I build to get the feel of things. I think we should close this issue and then pin it so that new developers do not think that the project is abandoned. |
|
To add to this, we're actively using Portier in production for multiple applications, and dozens of installations. These apps are not open to the public (they're backends for various sites and web apps), but actively used by ourselves and customers.
No retries on code input is definitely something I consider a bug, though I don't think there's an issue in our tracker for it. It's been on my mind for a while, but funnily enough I've never heard any of our users complain. So there's been no pressure for me to implement it. 🙃 If the link fails in a different browser context, that sounds like the relying party is rejecting it? The links should generally work in any context, but if the RP connects it to some specific pre-existing state, then I'm not sure if fixing that is within our control. (Common failure is that the RP stores the login session / nonce in a cookie. I try to add warnings about this in the official Portier client libraries, but maybe we should do more.) |
I suspect the Venn diagram of your users and our users does not overlap, you obviously have a better potato grader...
100%, I only flagged it here for the OP to be aware of a glitch they are likely to stumble into. |
Created an issue to highlight that you have a higher quality batch of users than we do... @stephank If there is anything I can do to help, then do ask; there is the option for me to sub-contract the work to you... |
Hello! I have been following this project closely for quite a long time. I was wondering if this project is suitable for real world usage. Nothing mission critical, just want to try it out on a side project to assess it's viability. Would love to get some pointers here!
Awesome work with the project BTW!
(PS: I would have opened this as a discussion but I think that tab is disabled.)
The text was updated successfully, but these errors were encountered: