Bug #9114
closed
Captive Portal Blocked MAC Address Redirect URL not working
0%
Description
Prior to version 2.4.4-RELEASE, devices listed in Captive Portal "MACs" section would never see a login prompt, and devices marked "Block" would be redirected to the URL found in the "Blocked MAC address redirect URL" when attempting access. In this case we are using an IP address on the same subnet as the device so there should be no reason for authentication of the blocked device before redirecting.
Starting in version 2.4.4-RELEASE, a device marked "Block" is being prompted for a user ID and password before being redirected, which is incorrect behavior.
Thank you
Files
Updated by A FL over 5 years ago
Forum link: https://forum.netgate.com/topic/137627/blocked-mac-address-redirect-url-not-working
Well,
It is true that a device marked "Block" must go through the captive portal login page before being redirected or getting an error message.
It is also true that this behavior is new since 2.4.4. In 2.4.3 and before, blocked users were redirected or got an error message before ever attempting to log in.
The reason why this behavior has been updated is that it was quite strange to display an error message before letting users enter their credentials first.
In my opinion, the captive portal should redirect users directly if a "Blocked MAC URL" has been entered, but should display the login page before displaying an error message if no custom URL is entered.
Updated by Polar Nerd over 5 years ago
The reason why this behavior has been updated is that it was quite strange to display an error message before letting users enter their credentials first.
The point of having a "MACs" tab is to prevent the login prompt for machines listed. The software should do exactly as the configuration field states: "Blocked MAC addresses will be redirected to this URL when attempting access." Not suddenly change its behavior after years.
Changing the behavior of software after a long established history is also a dangerous practice. There was no notification of the change, and there was no open issue that compelled the change. This kind of thing, if not accidental, tends makes the software untrustworthy. What else is going to change that will cause the system to stop functioning the way they need it? This change is costing my client money as they pay me hourly to get it working the way they want it.
Updated by Renato Botelho over 5 years ago
- Assignee set to Renato Botelho
- Target version set to 2.4.4-p1
PR merged. Thanks
Updated by Vladimir Lind over 5 years ago
Tried on 2.4.5-DEVELOPMENT (amd64) built on Tue Nov 20 16:55:31 EST 2018 (ran pfSsh.php playback gitsync master to be sure recent changes are applied).
Not seeing redirection to block page with enabled MAC block and block URL with IP from the lan subnet.
Updated by A FL over 5 years ago
Vladimir Lind wrote:
Not seeing redirection to block page with enabled MAC block and block URL with IP from the lan subnet.
Are you sure? I confirm that I see a redirection to the block page when block URL is filled. It works both with an URL pointing to an IP within the lan subnet, and with an URL pointing to an external website (if this website has been previously added as allowed hostname, of course).
So that's a positive feedback for me. There is also positive feedback on the forum thread.
Could you give me more information about the steps you've done during your test? Maybe i've missed something...
Updated by Jim Pingle over 5 years ago
- Status changed from Feedback to Resolved
Based on multiple reports of it being fixed with this change I'd say it looks good. If someone has a different variation of this issue we can open a fresh ticket after 2.4.4-p1.