<p>Hello <a href="/r/golang">r/golang</a>. Today I put the finishing touches on Authboss v2's rc2. This was an extremely long time coming and so I'm very happy to have delivered on it finally.</p>
<p>Authboss helps solve http authentication (password recovery e-mails, user confirmation, oauth2) for the web. It's modular in that you can take what you want and nothing else, and it should integrate into any existing Go web stack fairly easily.</p>
<p>v2 was about flexibility and type safety and I'm happy to say it achieved both of these goals. Now it's time to collect feedback and do some finishing touches to see the full release which is why I'm announcing the rc and not the full release :)</p>
<p>Project link: <a href="https://github.com/volatiletech/authboss/tree/v2.0.0-rc2">https://github.com/volatiletech/authboss/tree/v2.0.0-rc2</a></p>
<p>Mailing list announcement: <a href="https://groups.google.com/a/volatile.tech/forum/#!topic/authboss/SBfx0Bc5PNE">https://groups.google.com/a/volatile.tech/forum/#!topic/authboss/SBfx0Bc5PNE</a></p>
<p>Hope it helps someone in their web adventures.</p>
<hr/>**评论：**<br/><br/>edevil: <pre><p>Thank you for your work. Re-implementing web auth is one of the things that keeps me going back to Django.</p></pre>aarondl: <pre><p>Yep. This is one of the biggest reasons my last more serious projects ended up being rails. One of my other big pain points is databases and for that I made <a href="https://github.com/volatiletech/sqlboiler" rel="nofollow">https://github.com/volatiletech/sqlboiler</a> I mention it because maybe you share that pain not being able to use flask or what have you. :)</p></pre>edevil: <pre><p>Seems great! I'm keeping it bookmarked.</p></pre>ChristophBerger: <pre><p>Be aware that <code>go get</code> always fetches the master branch.</p></pre>vic3lord: <pre><p>vgo get fixes that :)</p></pre>ChristophBerger: <pre><p>True but vgo is still an experiment. Many (if not most) Go users rely on a stable version of the Go toolchain.</p></pre>vic3lord: <pre><p>I agree</p></pre>mvrhov: <pre><p>Nice. </p>
<p>I don't like the way tokens reset/confirm are implemented. </p>
<p>IMO <a href="https://paragonie.com/blog/2017/02/split-tokens-token-based-authentication-protocols-without-side-channels" rel="nofollow">Split tokens</a> as described in the linked post are the secure way. And while in RC it's still time to fix that.</p></pre>aarondl: <pre><p>Will be looking at this in the coming days. Thanks for the link! </p></pre>i-dontevenseethecode: <pre><p>What’s the license?</p></pre>jere_jones: <pre><p>MIT</p></pre>Xeoncross: <pre><p>Authboss looks very complete and promising. Thanks for your work.</p>
<p>I'm wondering what type of overhead this adds to each HTTP request. I see tests but could you add some benchmarks? I would love to see allocs and memory usage.</p></pre>aarondl: <pre><p>Thanks for your kind comments. In terms of performance in Authboss there's two areas that we could be looking at.</p>
<p>1) Authboss routes: this is logging in/out, confirming users etc. This stuff should all be accessed quite infrequently compared to the rest of the site, so I'm pretty unconcerned about performance here.</p>
<p>2) The rest of your site: Authboss supplies a few <a href="https://github.com/volatiletech/authboss-sample/blob/96684a765cfb0b28b3f663de7e0c1fc512b60616/blog.go#L228" rel="nofollow">middlewares</a> that you might want to use in your app. One of the main reasons I'm not really concerned about these either is because they're very small and completely rewritable since Authboss doesn't hide anything and also all these middlewares are really doing is querying the database with code you wrote and doing session/cookie management with code you wrote and so the hotpaths would probably involve your own code if not more than Authboss code.</p>
<p>So having said that performance isn't really a concern I currently have with this code (mostly because I'm starting on sqlboiler v3 now and I'd like to focus on that). It's not zero allocation because there's context.Context in use as well as a custom ResponseWriter, but I don't think there's anything prohibitively expensive but of course that depends on the use case. All abstractions come at a cost unfortunately.</p>
<p>Importantly however, if someone raised performance concerns, or contributed benchmarks like you're wanting to see (hint hint) and things weren't where they should be I'd commit to help fixing. I like fast and efficient things too! Thanks for bringing up the topic.</p>
<p>edit: grammar</p></pre>
