Error handling in external CWP

  • 1
  • Question
  • Updated 9 months ago
I have an External Capture Web Portal that we created a few years back, and it mostly works great. Getting the requests, displaying the page, using Facebook login, One Time Codes for Mobile, non-expire users etc all works as expected, with one exception.

When a user types the wrong password, the user is redirected back to the eCWP as expected, BUT the URL-parameter "autherr" does not indicate that there was a problem with the authentication, it remains set to "0".

Are anyone else having this issue? We are on a mix of 6.4 up to 7.1 software on our APs, mostly 230's and some 250's, around 1500 of them currently deployed. Just upgraded to the latest HiveManager, self-hosted version.

The AP I'm testing on currently with the newest version of our eCWP GUI, is on version 7.1.

Thanks!

-Morten
Photo of Morten Olsrud

Morten Olsrud

  • 8 Posts
  • 0 Reply Likes

Posted 10 months ago

  • 1
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
HiveOS 6.4 thru 7.1? There have been almost too many bug-fixes to list between your 6.4 release and the current latest for those platforms which is version 6.5r8. I suggest you try upgrading to this version of code to see if the experience gets any better. If for some reason it does not, then our Tech Support and engineering team will then at least be looking at the code they're most familiar with while assisting you. Likewise, the equipment that was launched on version 7.x of HiveOS can and should all be upgraded to HiveOS version 8.1r2.
Photo of Morten Olsrud

Morten Olsrud

  • 8 Posts
  • 0 Reply Likes
Please se my additional comments below. 
Photo of Morten Olsrud

Morten Olsrud

  • 8 Posts
  • 0 Reply Likes
Well, we have upgraded a lot of AP's now. Quite a few now run on 6.5 Honolulu, which I believe is the golden image, as well as a lot running 8.1r1 or 8.0r1. I'm not seeing 8.1r2 available on my HM Classic, but I'll take another look. I'll get some tests done tomorrow to see if the "autherr" querystring parameter gets set to 1 when I supply an incorrect username or password. 

I'm also planning on experimenting with the option to redirect to an external site, where I'll just point then to the login page, but set a value in the URL myself. I just hope I get to keep the other querystring parameters when doing that.

I'll try to get an update postet when I know more. 

Thanks for your help so far.
Photo of Morten Olsrud

Morten Olsrud

  • 8 Posts
  • 0 Reply Likes
Well, I've confirmed that the AP I'm testing on is on the latest software, which is 8.1r1, and still I don't get the autherr parameter set to indicate erroneous credentials.

Anyone have any more ideas?
Photo of Morten Olsrud

Morten Olsrud

  • 8 Posts
  • 0 Reply Likes
Just found 8.1r2 on your webpages and manually uploaded it to the HM, upgraded the testing AP and still no dice... 
Photo of Morten Olsrud

Morten Olsrud

  • 8 Posts
  • 0 Reply Likes
Ok, I've been digging through some network traffic trying to get some clues to the problem, and also trying to look for alternate ways to detect failed login attempts. What I have discovered is that when I post the login form, including all the parameters from the query string, to https://somepage.whatever/reg.php, I get redirected to the initially requested page. This happens regardless of whether I have that setting enabled under the "Successful Login Settings", or not. 

It actually does not try to redirect med back to the login-page, but rather sends me there through a detour. I believe this is what causes the problem with the "autherr" parameter not being set, as the "state" of my session when I hit the eCWP again, is actually that it is a fresh redirect, with no history of being there before.

Example flow:
Connect to SSID with eCWP -> try to navigate to google.com in browser -> redirected to eCWP -> try to login with invalid credentials (post to reg.php) -> 302 redir to google.com -> redir to eCWP

Why is this happening? Bug or feature? If feature, how do I avoid it, and if bug, is there a known workaround?

Thanks again for your help!

Regards

-Morten
Photo of Jonas Mellander

Jonas Mellander, Systems Engineer, Nordics and Baltics

  • 8 Posts
  • 0 Reply Likes
Isn't the problem here on the eCWP code (as opposed to the AP side), in that it does not set the autherror value to something other than 0 when authentication fails?
Photo of Morten Olsrud

Morten Olsrud

  • 8 Posts
  • 0 Reply Likes
I was under the impression that the AP was to set the autherr to 1 so the eCWP can know that the RADIUS rejected the request. The eCWP has no way of doing this check against the RaDIUS other than through POSTing to the reg.php endpoint where the AP picks up the request and checks against the RADIUS.
Photo of Jonas Mellander

Jonas Mellander, Systems Engineer, Nordics and Baltics

  • 8 Posts
  • 0 Reply Likes
Oh, maybe I misunderstood it. There is one option where you have eCWP but with local authentication (RADIUS) and one where the eCWP does the authentication and posts back the result. I thought you were on the latter.
One idea is to look at the RADIUS response when authentication is failing. Perhaps there's some attribute or value in there which triggers a bug of some sort? Feel free to send me a capture of the RADIUS.
Photo of Morten Olsrud

Morten Olsrud

  • 8 Posts
  • 0 Reply Likes
Could you point me to the documentation for the latter case for HM Classic? That would possibly be a workaround.