Admin url questions


 

Colin Bonstead

TVWBB Member
I'm looking into adding admin support to my app. I read through the urls and commands page on the wiki and tried to figure out a command string for changing the setpoint. It seems like it should be something like this:

http://server/luci/lm/set?sp=250

That just gives me an error message though. I went to the normal webpage and clicked the login link and typed in my password. After that was done I was at a page like this:

http://server/luci/;stok=biglongtoken/admin/lm/home/

I tried just changing that url to be the one I tried before, but with the token in there. So, something like this:

http://server/luci/;stok=biglongtoken/admin/lm/set?sp=250

I had to add the /admin/ part too, but that makes sense since I'm doing something that should be admin only. It worked though, my setpoint was changed. My question is, is this the correct way to do this? The only part that seems a little problematic is the login. I'm used to standard HTTP auth, where when you request a protected url you supply the login and password as parameters to the url request (I'm talking about doing this from code, not a browser.) Is there a way to login to the HeaterMeter with just a url, and not having to actually parse the login webpage? Also, am I expected to store the token and make it part of the url? That's not really a big deal, as long as I login and get it without having to do any scraping or something like that.
 
Ah yes, thanks for bringing up that /lm/set is now /admin/lm/set. I forgot to change that in the wiki when I moved it. Wiki updated!

The reason the website doesn't use standard "basic auth" to protect the pages is because it is insecure. Imagine that you've logged into your HeaterMeter using the standard popup authentication deal. Your bbq is smoking nicely and you've got nothing to do so you also decide to visit these forums. Imagine that I'm a jerk and I post an image like with this url:
<img src="http://heatermeter/luci/admin/lm/set?sp=500">

Your browser will then generate an authenticated request to your heatermeter and change the setpoint to 500 degrees just by you viewing the page. This is know as a "cross site request forgery" and is the reason there's that random session string in the url. There's other ways to avoid this too. One would be to require that all commands that change parameters come via POST parameters instead of GET, which sucks because you can't just build a URL yourself. Believe me, I've built hundreds of URLs myself as I developed this project. Also, the original HeaterMeter v1 didn't support POST parameters, only GET params, so the original design just never supported them.

That's the background, which I'm sure everyone finds super interesting, right? Just tell me how to make it work! Enabling Basic Auth in the wiki. Create a secondary path on the web server which allows basic authentication. When you call URLs with the http://user:password@site/mybasicauthprefix/ it will just work, as long as you don't supply a sysauth cookie, which why would you do that, right?
 
Cool, thanks for the info Bryan. I don't want to make people have to telnet into their HeaterMeter to enable this though, so I'll try to be a man and scrape it. That login page is pretty simple, so it might not be a big deal.
 
You don't have to scrape it if you want a full login kajigger. Any of the authenticated pages will accept the usename and password as POST parameters and automatically log you in.

On the surface you might say "welp, that solves that problem!". However, if you don't pass back the cookie and proper session URL token, the server creates a new session for you for each request. Again, you might say "welp, that saves me the trouble of storing the session data!". It works fine for a few requests, but given that the session timeout is 24 hours, and each session creates a data file, this can add up pretty quickly. I think there's a problem in luci where it validates all the session files on every access which can really drag down the server. I never looked into it because usually there's just a handful of sessions at any time. If a new session is created for every request you could really kill things.

To store the proper session data, all you need to do is store the 'sysauth' cookie which is sent in the response header. It contains both the sysauth cookie value you need to pass back on every request, as well as the url token in the 'path' field (replace the /luci/ part of your request URLs with the path value).
 

 

Back
Top