www: url_helpers: Pass username as a const to username_to_name()

Signed-off-by: Andrew Clayton <andrew@opentechlabs.co.uk>
www: utils: Unlink the temporary files when cleaning up

Remove the temporary files POSTd to us, in free_u_files()

Signed-off-by: Andrew Clayton <andrew@opentechlabs.co.uk>
www: receiptomatic: init_logs() needs to come after get_config()

Seeing as we can set the log dir in the config file, we need to get this
before we set up the logs.

Signed-off-by: Andrew Clayton <andrew@opentechlabs.co.uk>
www: utils: Reduce the amount of memory needed for mime processing

When dealing with multipart mime post data in process_mime(). We read
the post data into a memory buffer then pass it over to gmime, this then
means we have two copies of the data in memory until we finish the
multipart mime processing and free everything.

What we can do instead is free our memory buffer immediately after
passing it over to gmime, effectively halving the amount of memory
required after that point to process the mime parts.

Signed-off-by: Andrew Clayton <andrew@opentechlabs.co.uk>
www: db: Only log SQL queries when debugging is enabled

While the sql log is useful for debugging, it can get real big real
quick.

Signed-off-by: Andrew Clayton <andrew@opentechlabs.co.uk>
www: utils: process_mime_part: Initialise file_info to 0

memset the file_info structure that we've just malloc'd to 0, to
prevent random contents from appearing in there.

Signed-off-by: Andrew Clayton <andrew@opentechlabs.co.uk>
www: utils: Make get_tenant() return a pointer to tenant also

This allows it to be used inside other functions, such as printf()

Signed-off-by: Andrew Clayton <andrew@opentechlabs.co.uk>
www: utils: Statically allocate the POST file name variables

Use NAME_MAX + 1 and PATH_MAX for the sizes of file_info.orig_file_name
and file_info.temp_file_name respectively,

We only need NAME_MAX + 1 for the original file name as we only ever
receive the filename component in the POST data. It's also worth noting
that PATH_MAx includes the nul byte.

This saves 2 malloc's/free's

Signed-off-by: Andrew Clayton <andrew@opentechlabs.co.uk>
www: Statically allocate various structure members

Statically allocate various members of the user_session structure.

This also fix's a bug in get_tenant(), we ere doing a sizeof(tenant) in
the snprintf(), but tenant is a pointer and the sizeof() will return the
size of the pointer not the actual size of the storgae.

We now use TENANT_MAX + 1 in there.

Signed-off-by: Andrew Clayton <andrew@opentechlabs.co.uk>
www: utils: Introduce a generic hash generation function

There are various places where we want a hash to use as a key or some
such. So rather than having multiple slightly different hash functions,
consolidate them into one.

Signed-off-by: Andrew Clayton <andrew@opentechlabs.co.uk>
www: url_helpers: Use generate_hash() in create_session()

Switch to the new generate_hash() function from create_session_id()

Signed-off-by: Andrew Clayton <andrew@opentechlabs.co.uk>
www: url_helpers: Switch to generate_hash() in generate_csrf_token()

Signed-off-by: Andrew Clayton <andrew@opentechlabs.co.uk>
www: url_handlers: Switch to generate_hash() in generate_new_key()

Signed-off-by: Andrew Clayton <andrew@opentechlabs.co.uk>
www: url_handlers: Switch to generate_hash() in forgotten_password()

Signed-off-by: Andrew Clayton <andrew@opentechlabs.co.uk>
www: url_helpers: Switch to generate_hash() in do_add_user()

Signed-off-by: Andrew Clayton <andrew@opentechlabs.co.uk>
www: Remove redundant hash generation functions

With the introduction and switch over to generate_hash(), the
create_session_id() and generate_activation_key() functions are no
longer used.

Signed-off-by: Andrew Clayton <andrew@opentechlabs.co.uk>
www: utils: generate_hash: Reduce the amount of entropy used

Various bits of the application want to generate a unique key/id and use
a SHA-256 hash for this purpose. To create this hash, we were taking
1024 bytes of data from /dev/urandom.

However, the kernel's entropy source is not endless (without the
employment of HWRNGs) and 1024 bytes is way excessive for its uses
here. Assuming you get the full 256 possible values of a byte from the
entropy source, 1024 bytes could produce 1x10^2466 unique hashes.

That does seem to be the case, in a test creating a million hashes using
1 byte of entropy, produced 256 unique hashes each with ~3-4000
duplicates.

So, lets reduce the number of bytes used to 8, this can produce 256^8
(1.8x10^19) unique hashes. Which I think suffices for things like one
off activation keys, CSRF tokens and even longer lasting things like
session ids.

Also, due to the way the hashing algorithm works, a minor change in
input will generally lead to a very different hash.

Several runs of creating a million hashes using 8 bytes of entropy
produced no duplicates. It's also worth noting that in this case,
producing duplicate hashes over the lifetime of the application
wouldn't generally be a major issue.

Signed-off-by: Andrew Clayton <andrew@opentechlabs.co.uk>