auth_key api for different situations

[pliablepixels]

#2089

@connortechnology - take a look.

Seems to work for me, but I noticed that User.Password actually stores the MD5 encoded password, not the real password. So &user=&pass= pbly won't work - I suppose we need to load some other model for the password?

[pliablepixels]

ok, so &pass= is by design, not supposed to send the password, as its never stored in raw form. I'll modify the PR to return just user=<user>&pass= so the user knows he needs to append as password. Better then not returning &pass= because then the API recipient needs to figure out if it was plain setting.

[pliablepixels]

Our API JSON setup leaks logs/warnings from other functions. Specifically, getAuthHash function in auth.php generates several messages (example password hash is not a valid index if auth is not builtin, or, it does a session start when a session is already started etc). These "messages" leak out into the JSON api, which should not happen. I've fixed that by doing a $this->view = 'Json'

Output produced:

1. OPT_USE_AUTH + AUTH_TYPE = builtin + AUTH_RELAY = hash

{
    "auth_key": "auth=40383890ec0e5e66<etc>f",
    "append_password": 0
}

2. OPT_USE_AUTH + AUTH_TYPE = builtin + AUTH_RELAY = plain

{
    "auth_key": "user=admin&pass=",
    "append_password": 1
}

3. OPT_USE_AUTH + AUTH_TYPE = builtin + AUTH_RELAY = none

{
    "auth_key": "user=admin",
    "append_password": 0
}

[connortechnology]

I don't think you need to do all the Config lookups. I think you can use the defines just like in the regular UI.

If auth=plain, then we store the password in the session, unhashed. If we are using auth=hashed then we store passwordHashed in the session as the hashed password. If we switch auth methods after logging in from plain to hashed, then the session will not have the unhashed password in the session.

auth=plain is inherently unsafe. We should really get rid of all of it, and use actual public key cryptography to encrypt a hash.