| With the small exception of IP address based access control, |
| requests from all connecting clients where served equally until now. |
| This chapter discusses a first method of client's authentication and |
| its limits. |
| |
| A very simple approach feasible with the means already discussed would |
| be to expect the password in the @emph{URI} string before granting access to |
| the secured areas. The password could be separated from the actual resource identifier |
| by a certain character, thus the request line might look like |
| @verbatim |
| GET /picture.png?mypassword |
| @end verbatim |
| @noindent |
| |
| In the rare situation where the client is customized enough and the connection occurs |
| through secured lines (e.g., a embedded device directly attached to another via wire) |
| and where the ability to embedd a password in the URI or to pass on a URI with a |
| password are desired, this can be a reasonable choice. |
| |
| But when it is assumed that the user connecting does so with an ordinary Internet browser, |
| this implementation brings some problems about. For example, the URI including the password |
| stays in the address field or at least in the history of the browser for anybody near enough to see. |
| It will also be inconvenient to add the password manually to any new URI when the browser does |
| not know how to compose this automatically. |
| |
| At least the convenience issue can be addressed by employing the simplest built-in password |
| facilities of HTTP compliant browsers, hence we want to start there. It will however turn out |
| to have still severe weaknesses in terms of security which need consideration. |
| |
| Before we will start implementing @emph{Basic Authentication} as described in @emph{RFC 2617}, |
| we should finally abandon the bad practice of responding every request the first time our callback |
| is called for a given connection. This is becoming more important now because the client and |
| the server will have to talk in a more bi-directional way than before to |
| |
| But how can we tell whether the callback has been called before for the particular connection? |
| Initially, the pointer this parameter references is set by @emph{MHD} in the callback. But it will |
| also be "remembered" on the next call (for the same connection). |
| Thus, we will generate no response until the parameter is non-null---implying the callback was |
| called before at least once. We do not need to share information between different calls of the callback, |
| so we can set the parameter to any adress that is assured to be not null. The pointer to the |
| @code{connection} structure will be pointing to a legal address, so we take this. |
| |
| The first time @code{answer_to_connection} is called, we will not even look at the headers. |
| |
| @verbatim |
| static int |
| answer_to_connection (void *cls, struct MHD_Connection *connection, |
| const char *url, const char *method, const char *version, |
| const char *upload_data, size_t *upload_data_size, |
| void **con_cls) |
| { |
| if (0 != strcmp(method, "GET")) return MHD_NO; |
| if (NULL == *con_cls) {*con_cls = connection; return MHD_YES;} |
| |
| ... |
| /* else respond accordingly */ |
| ... |
| } |
| @end verbatim |
| @noindent |
| |
| Note how we lop off the connection on the first condition (no "GET" request), but return asking for more on |
| the other one with @code{MHD_YES}. |
| With this minor change, we can proceed to implement the actual authentication process. |
| |
| @heading Request for authentication |
| |
| Let us assume we had only files not intended to be handed out without the correct username/password, |
| so every "GET" request will be challenged. |
| @emph{RFC 2617} describes how the server shall ask for authentication by adding a |
| @emph{WWW-Authenticate} response header with the name of the @emph{realm} protected. |
| MHD can generate and queue such a failure response for you using |
| the @code{MHD_queue_basic_auth_fail_response} API. The only thing you need to do |
| is construct a response with the error page to be shown to the user |
| if he aborts basic authentication. But first, you should check if the |
| proper credentials were already supplied using the |
| @code{MHD_basic_auth_get_username_password} call. |
| |
| Your code would then look like this: |
| @verbatim |
| static int |
| answer_to_connection (void *cls, struct MHD_Connection *connection, |
| const char *url, const char *method, |
| const char *version, const char *upload_data, |
| size_t *upload_data_size, void **con_cls) |
| { |
| char *user; |
| char *pass; |
| int fail; |
| struct MHD_Response *response; |
| |
| if (0 != strcmp (method, MHD_HTTP_METHOD_GET)) |
| return MHD_NO; |
| if (NULL == *con_cls) |
| { |
| *con_cls = connection; |
| return MHD_YES; |
| } |
| pass = NULL; |
| user = MHD_basic_auth_get_username_password (connection, &pass); |
| fail = ( (user == NULL) || |
| (0 != strcmp (user, "root")) || |
| (0 != strcmp (pass, "pa$$w0rd") ) ); |
| if (user != NULL) free (user); |
| if (pass != NULL) free (pass); |
| if (fail) |
| { |
| const char *page = "<html><body>Go away.</body></html>"; |
| response = |
| MHD_create_response_from_buffer (strlen (page), (void *) page, |
| MHD_RESPMEM_PERSISTENT); |
| ret = MHD_queue_basic_auth_fail_response (connection, |
| "my realm", |
| response); |
| } |
| else |
| { |
| const char *page = "<html><body>A secret.</body></html>"; |
| response = |
| MHD_create_response_from_buffer (strlen (page), (void *) page, |
| MHD_RESPMEM_PERSISTENT); |
| ret = MHD_queue_response (connection, MHD_HTTP_OK, response); |
| } |
| MHD_destroy_response (response); |
| return ret; |
| } |
| @end verbatim |
| |
| See the @code{examples} directory for the complete example file. |
| |
| @heading Remarks |
| For a proper server, the conditional statements leading to a return of @code{MHD_NO} should yield a |
| response with a more precise status code instead of silently closing the connection. For example, |
| failures of memory allocation are best reported as @emph{internal server error} and unexpected |
| authentication methods as @emph{400 bad request}. |
| |
| @heading Exercises |
| @itemize @bullet |
| @item |
| Make the server respond to wrong credentials (but otherwise well-formed requests) with the recommended |
| @emph{401 unauthorized} status code. If the client still does not authenticate correctly within the |
| same connection, close it and store the client's IP address for a certain time. (It is OK to check for |
| expiration not until the main thread wakes up again on the next connection.) If the client fails |
| authenticating three times during this period, add it to another list for which the |
| @code{AcceptPolicyCallback} function denies connection (temporally). |
| |
| @item |
| With the network utility @code{netcat} connect and log the response of a "GET" request as you |
| did in the exercise of the first example, this time to a file. Now stop the server and let @emph{netcat} |
| listen on the same port the server used to listen on and have it fake being the proper server by giving |
| the file's content as the response (e.g. @code{cat log | nc -l -p 8888}). Pretending to think your were |
| connecting to the actual server, browse to the eavesdropper and give the correct credentials. |
| |
| Copy and paste the encoded string you see in @code{netcat}'s output to some of the Base64 decode tools available online |
| and see how both the user's name and password could be completely restored. |
| |
| @end itemize |
| |
| |