My captive portal application is hosted externally, and I have customized login.html on the mikrotik to send the mac address and other details to the captive portal application.
After the user performs an appropriate action on the external captive portal (pays for service, etc), the captive portal authorizes the user's mac in RADIUS.
All this works well EXCEPT for this:
- When the user first connects, a RADIUS Auth-Request is sent, and the Mikrotik NAS receives back an Auth-Reject because the user hasn't paid yet
- The user is then of course listed in "/ip hotspot hosts" but not "/ip hotspot active"
- When the user pays and is authorized into RADIUS, as long as they are still in "/ip hotspot hosts" the Mikrotik NAS doesn't send additional Auth-Requests to RADIUS when the user makes attempts to browse the Internet...so even though RADIUS knows the user is authorized, the Mikrotik doesn't re-ask RADIUS and keeps them unauthorized.
- I currently have to manually remove the user from the "/ip hotspot hosts" list after they have been authorized into RADIUS to force the Mikrotik NAS to send a second Auth-Request for them, after which everything works as expected.
- Send a RADIUS CoA to the Mikrotik NAS after the user pays - I have tested and it seems that I can only CoA a user that has already been Auth-Accepted by RADIUS and appears in both "/ip hotspot hosts" and "/ip hotspot active". I can't CoA a user who was Auth-Rejected and is only in "/ip hotspot hosts" because the Mikrotik doesn't consider them active. The Mikrotik NAS seems to refuse the CoA.
- Enable "http PAP" in addition to "Mac" login in the hotspot profile. Have the external portal redirect the user back to /login.html?username=MAC&password=XXX on the Mikrotik after they have paid. This works, but seems sloppy. I think there is also a hole here where a person could use another user's already authorized MAC as a user/pass to login.
- Instead of Auth-Rejecting unauthorized users, Auth-Accept them with attributes that cause them still to be stuck in the captive portal. Use a CoA once they've paid to change them from limited to full access. This seems like a lot of work, and I'd need to figure out the right attributes for a "limited" Auth-Accept.
- Set "/ip hotspot login-timeout" to something very short, like 3 seconds. This removes any non-logged in users from the "/ip hotspot hosts" list every 3 seconds, and in practice means that almost every web request an unauthorized user makes generates a RADIUS auth request. This seems like what I want, I'm just not sure of the load on RADIUS and the Mikrotik that is created by this.
- Is my login-timeout approach the right one?
- Is there a way in a mac-login only scenario, without enabling "http PAP" for my external captive portal to trigger a new Auth-Request from the Mikrotik NAS / hotspot servelet for a previously Auth-Rejected user? I tried just hitting /login with no arguments, but this didn't work.