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
