HTTP Authentication

[paulk]

Is it possible to have multiple users and/or passwords for the HTTP server.  That is, to have one password make visible one set of pages (ie: setup, config, debug, etc), and the other for regular "data" pages.

[mark]

Hi

There is a define called VARIABLE_PAGE_AUTHENTICATION.
When this is set, the call back function fnHandleWeb() is called with the ucType value equal to 0x01. (This value is used to avoid typical ASCII character values and should probably be made into a project define). The application interface (fnHandleWeb()) can this decide whether a web side can be displayed (by returning APP_ACCEPT) or authentication requested (by returning APP_REQUEST_AUTHENTICATION).
This allows some pages to be accessed by every visitor (public) and other to be protected.

Note that CHAR *ptrData is a pointer to the file. In some cases the MIME type should be checked so avoid blocking images, etc. Eg. just authenticate on HTML content.

When the actual access is authenticated the routine
extern int fnVerifyUser(CHAR *cDecodedUser, unsigned char ucCheckUser)
is used. This allows only a single user in its present form (that it, one password and one user name taken from the parameter block or another source).
Therefore to allow multiple users it would be necessary to extend this to check for the user/password from a table (for example) rather than the one fixed one. This is not a difficult task of course.

Finally it would be necessary to combine a user with a range of web pages. The decision as to whether web pages are generally free or not (discussion above) has nothing to do with users - it is called at a time when the user information is not known and can only decided which pages are really public. To allow the routine to also match this to a set of web pages the call fnVerifyUser() will need to be extended to pass also the file name (eg. extern int fnVerifyUser(CHAR *cDecodedUser, unsigned char ucCheckUser, CHAR *ptrFileName)). This represents a change but is also not complicated.

It remains then to add the algorithm to find the user's name in the list, check the basic authentication, followed by checking that this user also has access to the particular web page requested.

To summarise: not all of these capabilities are available but such an extension is not that difficult - the most complicated part is in choosing the best algorithm for matching user's authority to specific web pages., including the best construction of a list of users, passwords and these web pages.


Regards

Mark

[paulk]

Hi Mark,

Once again, thanks for the quick reply.  I started browsing the code, and your summary will be a big help in this.  Do you think it would make any sense to include in the web page some sort of "server side" variable that would define which users had access to it?  This way, the pages could be protected via an "access level" (and therefore more generic implementation) rather than having to create a static list (or algorithm).

For example, if we used one of the web delimiters "£", with a "security level" associated with it as the first bytes in the HTML file (or some implementation like this), then the algorithm could check this against the current user's security level. Although I guess this wouldn't work well for binary data (images, etc)....which might be an acceptable limitation.

I'm not familiar with HTTP Authentication methods, but is the username / password sent with every HTTP request?  Who decides how long this data is good for (server or browser?), and do we have to mess with cookies, etc?

I will try to educate myself on this regard, but if anyone has any other input, I'd appreciate it.

[mark]

Hi Paul

The idea of keeping user access information in the web side is interesting. It would involve the file being read and interpreted but would serve as alternative to a fixed list somewhere else, so it good. User rights could be changed by loading updated web pages so it is more flexible. Keeping the data at the start of the file will help since it will be found faster.

The authentication is sent in every HTTP GET that the browser sends, which means that it is checked on every GET. The browser controls this and will always send the authentication, usually also when the web site is left and returned to later (using its cache to know what to send). It is usually only necessary to enter the name and password again after the browser has been closed and opened again. Generally there is no handling needed at the server for this.

Regards

Mark

[paulk]

I'm going to be looking into this a little more closely over the next little while, and potentially investigate other authentication methods.  I did notice that the current authentication method asks for credentials only if the "root" ie "/" page is accessed.

That is, if the user directs their browser directly to the "Kadmin.htm" page, they can specifically disable HTTP authentication and continue on to any page (including "/") without credentials.

Moreover, this HTTP Authentication method has not server controlled means of initiating a logout, so for sensitive applications, this may not be a good method.

How have other users tackled this issue?  It may not be a big deal for us at the moment, but that may change shortly.

[mark]

Hi Paul

With VARIABLE_PAGE_AUTHENTICATION it is possible to protect all pages - just return APP_REQUEST_AUTHENTICATION every time.

The protection of just the start side simplifies (and speeds it up) since it will be used for almost all first connections in practice.

Regards

Mark

[paulk]

Hi Mark,
Forgive me, but to fully implement the VARIABLE_PAGE_AUTHENTICATION, does a new case need to be added to fnHandleWeb() to handle the check of the page?  I don't see any cases that match the 0x01 ucType setting.

Therefore, the pseudo code would be:

Code: [Select]

#define VARIABLE_PAGE_AUTHENTICATION
...
    if (fnHandleWeb(0x01, (CHAR *)ptrptrFile, http_session) != APP_ACCEPT) { // check whether this page is protected
...
within fnHandleWeb():

Code: [Select]

switch ucType:
...
...
  case 0x01:
    <if file_MIME_type=HTML then>
      <if file is "protected"> return APP_REQUEST_AUTHENTICATION
       else return APP_ACCEPT   
    break;
...


[mark]

Hi Paul

Yes, this is correct.

The option was added recently and used in a test project - the decision in fnHandleWeb() never made it into the reference project so it will accept all connections as it is.

In the reference project there were a few fixed pages and so the decision was made by just checking the possible public pages but I do like your suggestion about embedding this info in the individual web pages (not HTML should however not be checked and generally allowed - as in fact in the test project).

I will update the reference project to include an example, and also add a define instead of 0x01 since it is in interaction between HTTP and user which should be standardised a bit more clearly.

Regards

Mark

[paulk]

Hi Mark,
In my attempt to start implementing this, I've been also educating myself on how webInterface.c works.  Although I know that this is an "example", it serves as a good template/start point for many web applications.

I've appended the fnHandleWeb functionality to the fnInsertString document I sent you a while back, I can upload this somewhere if you'd like.

Regarding the authentication, my thought process would be as follows:

1) If VARIABLE_PAGE_AUTHENTICATION is set, call fnHandleWeb with ucType set to 0x01 (or user defined)
2) fnHandleWeb (upon seeing ucType as 0x01), checks to see if the file is of HTML type.  If so, it looks at the FIRST byte of the file.  If this byte is set to £ (web delimiter), then read the NEXT byte (should be between 0-9).
3) The byte would symbolize a "security" level required for viewing of the page.
4) If the current session "security level" is equal to or greater than the page required security level, then return APP_ACCEPT, otherwise return APP_REQUEST_AUTHENTICATION

This scheme requires a new "global" variable for security level of the current session.  Default security level would be "0", and other security levels could be assigned based on a user list (the creation/maintenance of the user list is another subject).

If this is available, it would be prudent to add a fnInsertString function to output the current security level, such that the pages could be dynamically created based on the current session "security" level.  That is, a javascript or similar client side variable could display/hide links based on the current level.

I'm "thinking out load" with this for the moment...I prefer to bounce some ideas before I go too far.  If you see any problems with this, let me know.  Also, if you have a different implementation in mind, please let me know, so I don't re-invent the wheel.

[mark]

Hi Paul

I think that the basis is good.

Possibly an optional extra byte in the struct HTTP (in tcpip.h) containing the security level of the session would be appropriate. This can be filled out with the value based on the authentication achieved and used by fnInsertString() when generating web content. If HTTP_DYNAMIC_CONTENT is active it will pass the HTTP session pointer so that the user code has access to this and could manage multiple sessions, each with its own level.
Another possibility would be to use the HTTP_USER_DETAILS pointer in this struct (this is a void pointer and can be used to point to a table of such information).

Links available only to certain security levels can be controlled by simple string insertion or else by dynamic code insertion, as well as probably other techniques too.

Regards

Mark

PS. You are welcome to upload the web interface document - it may be best to do it in a thread of its own so that it can be easier found ;-)