critique of vibe.d

[Nick Sabalausky via Digitalmars-d]

On 7/9/2014 11:21 AM, Sönke Ludwig wrote:
> Am 09.07.2014 03:54, schrieb luminousone:
>> There is lots of missing little bits here and their, password hashing
>> functions that use crypt_(C) formated hashes.
>
> I was hoping for dauth [1] to fill that gap. It doesn't use the same
> format, but one with the same goal. I didn't actually try it out yet,
> though.
>

I admit I'm unfamiliar with this "crypt_(C) formated hashes", I'll look 
it up and try to support it. Anyone happen to have a link handy?

Also, if anyone has ANY issues/concerns/questions/anything about DAuth, 
PLEASE speak up or submit an issue at github. I want DAuth to work well 
for everyone :)

Speaking of DAuth future direction, I may as well mention this and open 
it for comment:

My plan ATM is to expand DAuth's scope a little, split it into about 
three main components (at different levels of abstraction) and rename to 
something less likely to be mistaken for an OAuth lib (DAuth is 
unrelated to OAuth).

I'm thinking of something like this:

"InstaUser Core": Basically what DAuth is now. Provides the two main 
primitives "Convert plaintext password to a salted hash" and "Validate 
plaintext password against a salted hash". Plus all the optional 
lower-level stuff like dealing with salts/hashes/etc directly, selecting 
hash algos directly, customized salted-hash formats, one-use tokens, etc.

"InstaUser Store": I've already started work on this locally. Basically 
a simple (compile-time, static linked) plugin architecture that provides 
basic user-management primitives (create user, change user's password, 
validate a password against a user, delete user, etc) with pluggable 
storage backends ("Stores") like MySQL. Various storage backends would 
be included.

"InstaUser Web": This would leverage vibe.d to provide an out-of-the-box 
working (and customizable) web-based register/login system. I expect 
that some applications may (or might not) outgrow this, but I think it 
would be fantastic for getting a login-based site off the ground and 
up-and-running. Or even just putting files (like webalyzer stats) behind 
a login that isn't "HTTP auth". I've written/maintained sooo many web 
login systems over the years I've gotten sick of reimplementing sooo 
many of the same things every time and backporting all newer 
improvements (Which is really the whole original reason I started DAuth 
in the first place).

An application can use *just* Core and omit the Store/Web stuff 
entirely. Or they can use it at the Store level. Or at the Web level. Or 
make direct use of all the levels.

Further in the future, "InstaUser" could possibly grow support for the 
"login in via Facebook/Gmail/OpenID/whatever" that seems to be popular 
now, or whatever other authentication systems may be useful.

"Destroy!"

>
> [1]: http://code.dlang.org/packages/dauth