Wifi Web Interface Authentication

[dedvalson]

Hi,

In looking over the code I see that there are some facilities for WiFiAuthentication in the libraries. However I can't seem to find any documentation or examples for this on the forum or elsewhere.

There appears to be a static authStr and a function called WiFiAuthentication.

Is this a working feature? If so, how does one use it.

Also, is there documentation of the various URLs supported by the software? I can't find that anywhere either.

Thanks,

Don

[rimai]

The authentication was created a long time ago, but not used much.
http://groups.google.com/group/reefange ... 960f6895c1
The documentation of the wifi protocol is not created yet.
This is a piece of the code that takes care of handling the URL
It is located inside ReefAngel_Wifi.cpp.

Code: Select all

 	if (strncmp("GET / ", m_pushback, 6)==0) reqtype = REQ_ROOT;
	else if (strncmp("GET /wifi", m_pushback, 9)==0) reqtype = REQ_WIFI;
	else if (strncmp("GET /r", m_pushback, 6)==0) reqtype = -REQ_RELAY;
	else if (strncmp("GET /mb", m_pushback, 7)==0) { reqtype = -REQ_M_BYTE; weboption2 = -1; bHasSecondValue = false; bCommaCount = 0; }
	else if (strncmp("GET /mi", m_pushback, 7)==0) { reqtype = -REQ_M_INT; weboption2 = -1; bHasSecondValue = false; bCommaCount = 0; }
	else if (strncmp("GET /ma", m_pushback, 7)==0) reqtype = -REQ_M_ALL;
	else if (strncmp("GET /v", m_pushback, 6)==0) reqtype = -REQ_VERSION;
	else if (strncmp("GET /d", m_pushback, 6)==0) { reqtype = -REQ_DATE; weboption2 = -1; weboption3 = -1; bCommaCount = 0; }
	else if (strncmp("HTTP/1.", m_pushback, 7)==0) reqtype = -REQ_HTTP;
	else if (strncmp("GET /sr", m_pushback, 7)==0) reqtype = -REQ_R_STATUS;
	else if (strncmp("GET /sa", m_pushback, 7)==0) reqtype = -REQ_RA_STATUS;

So, basically:
/wifi: returns "Reef Angel Controller Web Server" string
/r99: returns parameters and relay statuses
/mb: stores byte size number into internal memory
/mi : stores integer size number into internal memory
/ma: returns memory settings
/v: retunrs version
/d: stores new date/time into RTC
/sr and /sa are not used yet.

[dedvalson]

Hi,

I found the list of http URLs in the code.

What is strange is for me all of them work except /wifi. It returns an HTTP Error 324 (Empty Response). But here is what is worse, /wifi is being treated as /w and my system goes into water change mode!

I am running 0.8.5.18 libraries. The URL I am trying to use (that causes me to enter water change mode) is

http://192.168.1.120:2000/wifi

That is my internal URL, I don't want to publish the dyndns one because I want to stay out of water change mode.

Am I just doing something stupid?

Don

[rimai]

Oh, that was the new command Curt was trying to work out last week.
I guess you grabbed the libraries in between changes, because he said he had fixed that and changed to /mw and /mf for water change and feeding mode.

[dedvalson]

I assume that use of the login / password precludes the use of the RAClient and the iPhone app. Does anyone know if that is correct?

[rimai]

yeah... that's why it hasn't been used much.
You enabled authentication and then the client and the apps stop working
New updates are coming though that will let you use authentication and apps at the same time

[dedvalson]

I redownloaded the libraries and the problem went away.

Thanks.

Strange that the version number didn't change though.

Don

[dmolton]

I've recently added authentication support in the Client Suite, but I'm not entirely sold on it yet. when browsing to /wifi or using the Client I will get a failed response back from the controller more often than I would like. It's not a consistent error and seems to happen randomly. I notice issues more often when using the memory reading/writing functions Curt made available. I can only get a successful response 25% of the time when using /ma and have about the same success rate when setting individual memory location values. As soon as I remove the authentication from the sketch and wipe the user/pass from the Listener everything goes back to working as expected.. I feel pretty comfortable not using the wifi authentication for the time being.

[binder]

I redownloaded the libraries and the problem went away.

Thanks.

Strange that the version number didn't change though.

Don

The way the update utility works is it reads my master branch on my github account. I "try" to not touch it between updates but I have been updating it lately due to additions from Roberto for some new cool stuff.
So that's why it changed without updating the version number. My bad. We will have to work on keeping things "stable" in my master branch and doing the "bleeding edge" stuff on my dev branch.

curt

[wolfador]

I've recently added authentication support in the Client Suite, but I'm not entirely sold on it yet. when browsing to /wifi or using the Client I will get a failed response back from the controller more often than I would like. It's not a consistent error and seems to happen randomly. I notice issues more often when using the memory reading/writing functions Curt made available. I can only get a successful response 25% of the time when using /ma and have about the same success rate when setting individual memory location values. As soon as I remove the authentication from the sketch and wipe the user/pass from the Listener everything goes back to working as expected.. I feel pretty comfortable not using the wifi authentication for the time being.

I also had issues with the authentication with the iPhone app which is why it was removed. I think if we converted to a password only authentication instead of user/pass it might resolve some issues.

[binder]

Since we've got a topic going about the authentication string (and several developers involved), I'll add some comments that I've noticed. I've not had a chance to really do much more testing on things with the authentication though.

While adding in some new commands, I noticed some not working properly. When I added in the /w command for the water change, it screwed up the /wifi command. Using serial communications things worked just fine and the commands were processed as they came through without a problem. Using the web interface, /wifi never worked once I added in the /w command. I noticed that the serial interface brings in an entire string at once and the web interface goes through 1 char at a time.
What this means is that when we issue a command, such as GET /wifi, with the serial interface it's processed 1 time as "GET /wifi". With the web interface, it's processed multiple times with the comparison checks like this:
G
GE
GET
GET /
GET /w
GET /wi
GET /wif
GET /wifi

So as you can see, if there is a /w command, that will match before /wifi. The processing loop will go through numerous times before it matches properly. This could very well be what is happening with the authentication as well. It's trying to process the string as it gets it in and it's erroring out numerous times before it actually completes and successfully authenticates. That could be a long enough delay that the commands don't get processed properly thus resulting in a "less than perfect" success rate.

Like I said, I have not had a chance to really dive into the situation yet. It's looking to me like we may need to improve the way that we read the data from the serial interface and wait for a group/string of characters instead of it only reading 1 char and the processing the string, read another, process string, etc. This scenario only seems to happen with the web interface and not the true serial interface which makes it even more difficult to test and track down.

Side Note: I was able to notice this action the best when I was using the controller with the builtin wifi so I could communicate via the wifi interface AND have the serial monitor open on the other serial interface.

Anyways, that's my comments so far. If anybody has suggestions or ideas on things to try out, I'm open for suggestions. I should be able to work on this more hopefully later this week or into the weekend.

curt

[dedvalson]

Curt,

You are completely right about what was happening. When I sent the GET /WIFI I wound up in water change mode and the next command was ignored.

This gave me an idea.

Perhaps we should modify the protocol to include a command terminator. For Instance, every command would end with something like </GET> or even just a single & or other unused character.

This would stop all of this quite easily.

To maintain compatability with older clients this could be a modal thing. The Client would send a command like GET /pv2 which would mean "Switch to protocol version 2" and then we would start ignoring input till we get the terminator.

Just a thought.

Don

[rimai]

I'll look into why the authentication is not working.
The protocol used by the wifi is actually HTTP protocol. So, we can't just terminate with </GET>, but the HTTP header always ends in double CRLF.

[binder]

I'll look into why the authentication is not working.
The protocol used by the wifi is actually HTTP protocol. So, we can't just terminate with </GET>, but the HTTP header always ends in double CRLF.

Yeah, I was thinking something about reading until we get the CRLF and then processing it accordingly. Like I said, more testing to figure it out.

curt

[jemw]

When not using the Client Suite 2.2 (authentication does not work in Client Suite), I have had no problems accessing my controller using authentication. I have the following entry in my .pde file:
ReefAngel.Init(); //Initialize controller
WifiAuthentication("xxxx:yyyyyyyyy");

Where xxxx is the user name and yyyyyyyyy is the password.


To use the Client Suite, I just comment out the WifiAuthentication and download