Login by name? Not slug?

[thavn]

Hi,

I've had a lot of trouble logging in to Journal after setting it up and playing with the database. It took me some time to figure out, but I wonder if you shouldn't think through the login process again?

It currently checks the user's name and password, but the name field is a blob in the database which I think is a bit strange for a login value... And even more, on the Admin page it seems pretty clear that Name can be changed to something different, for instance the full name of the user, instead of just a short username.

So after I had changed the Name field to a long, proper name, I suddenly found myself unable to log back in. :-)

Would you consider modifying the login procedure to check the slug or email fields instead of the name field, or possibly allow a match on either of the three fields? I'd be happy to do the change for you, but I'm not sure if the current process is by design or not. In case you'd like to keep checking against the name field, I think it should be specified a bit clearer on the login page which data to input.

Also, I think this is an awesome project. I hope to start contributing a bit within the next few days.

Best regards, Tore M. Havn

[kabukky]

Hi Tore, I agree - that is confusing. I plan on revamping the login system in the near future, possibly using something like https://github.com/go-authboss/authboss that can handle password reset via email.

I was planning on adding authentication via email in addition to name then, but you are more than welcome to change it right now :) I think I'll even make email the official login method, as Ghost does it. That way there is no confusion when the user changes his name. I'm not so sure about slug. The slug is something the typical user won't have any knowledge of (even though it is basically just his user name in lower case). I don't think it's necessary once email is implemented.

Regarding the blob field in the database: That was a (debatable) design choice. All DB fields that might be output by a ghost helper (in a theme) are stored like this because they are handled as []byte in Journey (string concatenation is done via bytes.Buffer). It may have been better to convert the values into strings again before storing them in the database, but that wasn't on my radar at the time. But since all of those DB fields are read into []bytes by Journey, it might even be faster this way. I didn't do benchmarks on that.

Thanks for your input. I would love to have you contribute :)

Best, Kai