dm4-accesscontrol: let createUserAccount() accept SHA256 (pre-)encoded passwords

[Malte]

It looks like that currently one has to pass createUserAccount() the password un-encoded, in clear-text. What would helpful for adapting the sign-up plugin to dm 4.6 is that the password could be passed into this method already -SHA256- encoded.

Especially in the context of the sign-up module this would allow us to send the Credentials over the wire not in clear-text but -SHA256- (pre-)encoded.

[jri]

You could use the Credentials(JSONObject cred) constructor. It expects a JSON object with "username" and "password" properties. The password is expected to be SHA-256 encoded.

The Credentials(String username, String password) constructor is not meant to be called with credentials send over the wire.

For a regular createUserAccount(), as called by an admin user, the credentials (with password encoded) are POSTed in the request body. The DM-Webservice would then call the JSON-Credentials constructor automatically.

You could do the same with your GET request, sending the credentials in the request body. Your resource method would look like this:

@GET
... createUserAccount(Credentials cred) {
    ...
}

Note that the cred parameter has no JAX-RS annotation. JAX-RS calls this the "entity parameter" as its value is constructed from the request entity=request body.

However, Jersey will give you a warning at compile time:

WARNING: The following warnings have been detected with resource and/or provider classes:
  WARNING: A HTTP GET method, ..., should not consume any entity.

But it would work.

Sending a password as part of the request URI/parameters is not a good idea as it would not be subject of SSL encryption. A sniffed SHA-256 encoded password is as worthy as the password itself. SHA-256 is no encryption, but an encoding, like Base64. Decoding a SHA-256 value does not involve any cryptographic keys. SSL on the other hand is key-pair based encryption. However SSL encrypts only the request body, not the request URI or headers.

[Malte]

Yes, SSL will not encode the URI/parameters, thanks for the hint.

Nonetheless, i would still consider SHA 2 a hash function (and not only an encoding) which is (nowadays) not easily reversable and thus safe enough to be sent as an URL parameter.

But now to the problem:
Do you have an idea on how to get the payload into the body using a GET-request, because i am unable to send a GET request where the data|body is not transformed into and appended as URL Parameters. Neither with native JS (and the XMLHTTPRequest-object) nor with employing jQuery (and setting "processData: false").

This time (or currently) it seems to be everywhere (firefox, chromium) as the SPEC says (​http://www.w3.org/TR/XMLHttpRequest/#the-send%28%29-method) at 4.6.6: "If the request method is GET or HEAD, set data to null".

When firing a POST request "Credentials" get over the wire (in the body) and decoded from my resource fine (but here we have the "dm4.security.write_requires_login" setting in our way).

For now, until i know how to do it, i will revert back to using the GET method and sending the sha-encoded password and username to the resource (as before).

Thanks for your support and for sharing your knowledge.

[Malte]

BTW: This is the way i could work with initiating Credentials manually, using GET:

You could use the Credentials(JSONObject cred) constructor. It expects a JSON object with "username" and "password" properties. The password is expected to be SHA-256 encoded.

Thanks for the hint!