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 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'.
It's a case of either renaming 'login' to 'login.cgi' or redirecting requests for login.cgi to login. Likewise for 'logout'.
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.
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
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.
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.
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:
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
Code: Select all
<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>Code: Select all
1105WestA-Apt407.64.126.xxx.yyyAhhh, Byzantine hackery, gotta love it.
--Eric
Who is online
Users browsing this forum: No registered users and 66 guests