Hi Richard
This authentication is not a complete solution and could be implemented better. I need to explain some history so that you understand why it was implemented like this...
Originally the uTasker project started on the Freescale NE64 which has very limited RAM. The ethernet buffers (2xRx and 1xTx) can be set up to be 128, 256, 512, 1k or 1.5k in size - which, in the largest case, eats up almost half of the available 8k RAM in the chip. As can be seen by the chip configuration possibilities, it is foreseen that applications don't necessarily use full size Ethernet buffers and so the project was often set up to use say 512byte frames - this is no problem when working with TCP but not always enough for DHCP since it requires 1k Rx buffer to guaranty correct operation (UDP frame size which needs to be received).
If you look at how the authentication operates with HTTP you will see that the user name and password is sent by the client in every transaction, which means that it 'should' be checked on every connection. However, when using small rx buffers this was a problem since the clients also send quite a lot of extra data about which type of browser they are and what they support and can accept - usually enough to require at least 2 TCP frames just to send the GET when working with limited frame sizes (restricted by the Ethernet RX buffer, which is reported at TCP level so that the client doesn't send full frames). Unfortunately the authentication part tends to be somewhere at the end of the GET transaction, meaning that it often crosses Ethernet buffers (starts at the end of one TCP frame and ends at the start of the next), requiring an intermediate buffer to allow checking after the end has been found (see
cUserPass[USER_PASS_LENGTH] in struct
HTTP). This requires 24 bytes per HTTP socket to hold this information, plus a counter
ucAuth.
The next problem was when sending parameters with the GET. The parameters are always at the start of the frame and the authentication parts usually towards the end ( in following TCP frames, when longer that the available Rx buffer space). This requires saving the GET details - which can be quite long when varous parameters are passed - and only handling them once the authentication could be verified (some time later) in the case of it being spread over two or more TCP frames.
This would mean large intermediate buffers which would have been a big load on the already stressed NE64 RAM. [If the authentication were to be always at the beginning of the transaction - before the GET part - it would not have been a problem but, as explained, it tends to be towards the end...].
The workaround was to only authenticate on the first connection and then don't check any more.
When connecting to the server using IP address (eg.
http://192.168.0.3) the GET is always for a blank file ' '. Your tests showed it being '0', but this is only because you were connecting to the address + a file name (eg.
http://192.168.0.3/0Menu.htm). That is, you had probably been using the browser previosly and then, after activation of the new authentication mode, it was connecting to the same file. If you close the browser and try again with the IP address alone it will always require the authentication.
To cut a long story short, this is a back-door with activated authentication. I expect that there are some clever methods which would allow this to be achieved without requiring so much intermediate buffer space - perhaps it is never needed when using 1k5 Ethernet buffers (not sure though). But this is something which should perphaps be worked on to remove this present weakness... In fact I haven't looked at it again since its original development but it is certainly a possible Achilles' heel.
By the way, your method of activating is OK. fnStartHTTP() parameters determine the properties of the server and you can also use a trusted IP address which will also may unauthorised access more difficult.
Regards
Mark
