A couple of usability issues come to mind

awebster

A couple of usability issues come to mind...

In looking at the failure log for the captive portal, I can see numerous entries of USERNAME, Username, whilst the real account is username. Short of entering every possible combination of username into the user manager, is there a way of making the captive portal username case insensitive?

Is there a way for the captive portal to host the successful authentication landing page so the administrator doesn't have to setup a website just to show a landing page?

Thanks!

jimp

Captive Portal could certainly do that, but some auth backends (like RADIUS) are also case sensitive so it would have to default to the current behavior.

It's also something you can solve with a bit of JavaScript on your custom Captive Portal page, that forces the username to lowercase before submitting.

awebster

@jimp, I had a deeper dive into this, here's some of the rabbit holes that I've had a chance to explore and my thoughts:

1. Adjusting the username on the web page
The username is lower-cased using some JavaScript when the page is submitted.
Pros: Easy to do, can be done using custom portal login page.
Cons: Requires JavaScript on the client device. No control over the client device.

2. Captive Portal back-end adjusts the submitted username
The username is lower-cased by the receiving php captive portal login script on pfSense.
Pros: Transparent to the end-user; works without JavaScript.
Cons: Requires customization of captive portal php code. php code uses authentication mechanisms that are pretty deeply integrated into pfSense code, so just lowercasing everything might cause other unexpected issues.

3. Creating duplicate usernames
As in username, USERNAME, Username
Pros: Transparent to the end-user; works without JavaScript.
Cons: Nightmare to manage!

4. Using RADIUS as an authentication back-end
Requires modification of FreeRADIUS to work, but can be configured to be case-insensitive.
Some further customization of FreeRADIUS config pages could include a checkbox to enable / disable (default disabled to preserve backward compatibility) case insensitivity
Pros: Transparent to the end-user; works without JavaScript; moves the case sensitivity outside pfSense per-se
Cons: FreeRADIUS, as installed by the package installer, disables the filter_username filter (which is initially broken), requiring modifications to /usr/local/pkg/freeradius.inc to uncomment the filter_username. Doesn't survive an upgrade.

5.Using LDAP as an authentication back-end
Windows AD LDAP is case-insensitive -- we have a winner!!!
Pros: Transparent to the end-user; works without JavaScript; moves the case sensitivity outside pfSense per-se
Cons: Requires back-end LDAP (AD) and associated infrastructure.

Gertjan

Use the captive portal login page (and error page) to indicate a message to the user that user names (and passwords) are case sensitive.

User that login, should 'write' (= read) which means they can read. So this auto solves.

edit : numerical user names / identifications will also remove the issue.

awebster

@Gertjan,
Good suggestion, and certainly usable in certain situations; sadly, I've found that people don't read instructions, and since it is a usability issue pushing it back onto the user only makes them feel frustrated, specially if they are under pressure, and the last thing you want is some self important upper management type complaining that the guest Wi-Fi doesn't work and their guests can't get on, all because they couldn't read the instructions properly.

Gertjan

I agree totally.

People that use devices to connect to the Internet are aware of the fact that an capital X and small case x are not always the same.

I know - again : we as a company still receive, ones in a while, mails in all capitals - or all lower case. Better yet : check out this forum, you will find the same thing.

Btw : forcing whatever is entered as a user name to capital ? No big deal.
Find line 216 in /usr/local/captiveportal/index.php

Here it is :

$auth_result = captiveportal_authenticate_user($user, $passwd, $clientmac, $clientip, $pipeno, $context)

Surround $user with "strtoupper" like this :

$auth_result = captiveportal_authenticate_user(strtoupper($user), $passwd, $clientmac, $clientip, $pipeno, $context)

This will force whatever the user entered, to capitals.

True : when pfSense updates, you will have to redo this edit - ones or twice a year.
A small shell script that starts when pfSense reboots could do this for you.