I have an issue trying to get a RouterOS 2.8.28 hotspot to accept an authorization reply from a backend server.
The server uses https://routeros_gateway/login.cgi?blahblah whereas RouterOS expects https://routeros_gateway/login?blahblah.
There isn’t any way to change the URL the server uses (stupid I know, its set in stone in closed source). Is there a way that I can tell RouterOS to either accept using login.cgi or redirect requests for login.cgi to login?
Thanks.
i don’t think that you will be able to make CGI files work on the hotspot router.
I tried a simple cgi redirect page (login.cgi that redirects to login) and that didn’t work, don’t even know the path to perl/python or whether the webserver supports it. I tried a javascript redirect that works when using a browser, but the server doesn’t support javascript (funny since its a jboss server, but understandable).
It’s a case of either renaming ‘login’ to ‘login.cgi’ or redirecting requests for login.cgi to login. Likewise for ‘logout’.
the only way that you can do this is with javascript. because there is no way you can tell hotspot to treat CGI as a normal login page
I don’t think I’m getting my message across.
The server is sending a URL to routeros with the exact parameters required for the hotspot to conduct a radius auth for a given user. It just thinks that the NAS should have a .cgi there to handle it - RouterOS doesn’t, it just uses login - however it takes the same URL parameters. It pretty much matches what’s written in the manual for authorization on a remote server - bar the return URL.
So I don’t need to run any CGI on the hotspot, I just need to run the existing ‘login’ but telling the server that is the catch.
I’ve made arrangements to obtain the appropriate source of the server under a NDA. I will attempt to create a new access controller profile to suit a MT Router. Currently there’s support for Gemtek, Colubris and Nomadix AC’s.
For similar situations, we do this:
Have the MT redirect the client to the login server, passing along the necessary variables.
The server then performs the necessary authentication and setup tasks, including the creation of a proper entry on the radius servers. It then responds to the client with a small chunk of javascript, containing the necessary parameters to pass back to the MT.
The client executes this javascript (if they don’t have it enabled, it tells them to enable it, or call us), which posts the necessary login information back to the MT.
The MT, upon recieving the post from the client, authenticates them against the radius server (using the information the login server set up in the first place), and grants them access (if successful).
It’s not perfect, but it seems to work pretty good for us. We can setup the back-end login server to do whatever we want for actual authentication, even checking external authentication systems first (such as checking against university records, before allowing dorm logins).
You can even take it so far as to time limit them with an expiring radius entry (and kick script), and add an extra layer of security by having a traceable and verifiable hash passed around between all the involved systems.
–Eric
That’s excellent eflanery - I did start thinking about using the client as the redirector when I was needing to use javascript.
Would it be too much to ask for an example of the script that is sent back to the client?
The server allows custom ‘per location’ content, I could sneek the javascript in after the login stage.
Here is a simple one, used as login.html on a MT. This one does not quite work as I described; in this case, the client based redirection only happens on the MT → server link, does not involve radius, and the server does not send back further javascript. The actual enabling is done via a persistant SSH session into the MT, disabling the hotspot, and seting it up for standard service (semi-permanent activation of apartment-unique VLANs). The one I described above will take some more time to redact, I’ll take a look in the morning.
<html>
<head>
<title> Please wait... </title>
<form name="redir" action="http://www.fsr.com/XXXXXXX/signup.asp" method="post">
<input type="hidden" name="VLan">
<input type="hidden" name="MTIP">
</form>
<script language="JavaScript">
re = /(.*)\.(.*\..*\..*\..*)/;
res = re.exec("$(hostname)");
document.redir.VLan.value = res[1];
document.redir.MTIP.value = res[2];
document.redir.submit();
</script>
</head>
<body>
JavaScript must be enabled in your browser in order to use the auto-signup system.
<p>
If you can not or will not enable JavaScript,
please call First Step at (XXX)XXX-XXXX to manually activate service.
</html>
I’m also abusing the “$(hostname)” variable given by the hotspot, to pass extra info back to the client. Here is an example of the “DNS name” field from one of the hotspot profiles, which the regex in the javascript cuts apart:
1105WestA-Apt407.64.126.xxx.yyy
The part before the first “.” is the name of the VLAN interface to mess with, and the rest is the IP address of the MT on which to mess with the VLAN (which the server uses as a referance to a COM object it maintains, which represents a persistant SSH session to the MT. “safe mode” is used as a lock, to prevent multiple servers from operating on the MT at the same time, as well as making the changes atomic).
Ahhh, Byzantine hackery, gotta love it.
–Eric
we will make it work with login.cgi and logout.cgi - next version will support it
Thanks for that Normis (and the rest of the Mikrotik staff for that matter).
I can forward you a document that discribes the interaction between the particular server I’m using and the access controllers if you like.