Wireless Access

I would like to host my captive portal on an external server, e.g. https://server1.fsu.edu.

In my Captive Portal Authentication Profile I have defined the "Login page" attribute as "https://server1.xyz.edu/index.php".  This page is rendered without any difficulty at the point where the user attempts to browse.  However, when the user submits their credentials, the browser just spins.  Here is the relevant html:

<form method="post" action="https://wireless.xyz.edu/auth/index.html/u" id="regform" autocomplete="off">
<label for="user" accesskey="u"> <h3>USERNAME</h3> </label>
<input type="text" name="user" id="user" accesskey="u" value="<?php echo $_SESSION["phone"] ?>">
<label for="password" accesskey="p"> <h3>PASSWORD</h3> </label>
<input id="password" name="password" type="password"  accesskey="p">

Does the system support this?  In particular, is the "action" allowed to call from the captive portal server to the controller, as shown?  Am I doing something obviously wrong?  Should I be taking a different approach to submitting captive portal credentials to the controller from an external server?  BTW - The exact same page works just fine when it is hosted on the controller (obviously action="/auth/index.html/u" in that case.)  We are on AOS 6.4.3.4.

Did you replace the controller's captive portal certificate? If yes, the name needs to be wireless.xyz.edu for this to work. When a user is associated to the Captive Portal, have the user try to ping wireless.xyz.edu to see if it resolves to the IP address of the controller.

OK, I must have had a bad test case last Friday because repeated tests today have all been successful.  I cannot reproduce a failure.  However, a different question has come up.  There are two cases:

1. The user already has credentials:  They connect to the SSID, browse, get redirected to the captive portal, authenticate, then get redirected back to the original page they wanted to browse to.  Works great!

2. The user does not already have credentials:  They connect to the SSID, browse, get redirected to the captive portal, CLICK A LINK TO ANOTHER PAGE where they register and receive credentials and then get returned to the captive portal.  Upon authenticating, instead of being redirected back to the page they wanted to browse to, they get a page that says:

"User authenticated"

"Press control-d to bookmark this page"

<button>LOGOUT</button>

 

Is there some way to bypass this "User authenticated" page and direct the user back to the page they wanted to browse to?

 

On the first association, the redirect URL contains the website that you originally requested.  If you do anything else besides put a username and password in, it might not be possible to further redirect that user.

 

With regards to the "logout" box showing up, can we see the configuration of your Captive Portal Authentication profile assigned to that SSID?  There is a "logout box" option that you can uncheck, but the Welcome Page URL also could be configured wrong.

Colin - Thank you for your thoughts and time.  The issue has been resolved.  Read on if you want to know how.

When the controller redirects the user to the Captive Portal (CP), the URL to the CP (URL-CP) includes a "query string".  The query string contains key-value pairs for info like the MAC and AP and also includes the URL of the Web page the user initially tried to browse to when they got redirected (URL-User).  If the user simply authenticates from the CP then the controller, probably via a cookie, has the URL-User info and can send them on to that page upon authentication.  But if the user leaves the authentication page to visit the registration page (or any other page), the query string is lost.  So when the user returns to the authentication page they no longer have a query string as part of the URL-CP. Then, upon authentication, since the controller does not see a landing page in the query string, it sends the user to a page announcing that they have been successfully authenticated.  This page includes a "Logout" button so that the user can return to it when they want to terminate their connection and leave the network.  This page should not be confused with the "Logout" page, which is where the user would be sent if they clicked the "Logout" button.

So, to accommodate this situation, the CP authentication page needs to capture the query string and pass it to any other page it might visit.  The visited page needs to catch the query string and then send it back when the user returns to authenticate.

A better solution would be a Single-Page Application (SPA).  But it would be a significant undertaking to rewrite the Authentication/Registration pages as an SPA.  It was trivial to capture the query string and pass it back and forth.

Thanks again, Colin.