Project

General

Profile

Actions

Bug #9114

closed

Captive Portal Blocked MAC Address Redirect URL not working

Added by Polar Nerd about 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Normal
Category:
Captive Portal
Target version:
Start date:
11/13/2018
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.4.4
Affected Architecture:
amd64

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

example.jpg (49.3 KB) example.jpg Polar Nerd, 11/13/2018 06:33 AM
Actions #1

Updated by A FL about 3 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.

Actions #2

Updated by Polar Nerd about 3 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.

Actions #3

Updated by Renato Botelho about 3 years ago

  • Assignee set to Renato Botelho
  • Target version set to 2.4.4-p1

PR merged. Thanks

Actions #4

Updated by Renato Botelho about 3 years ago

  • Status changed from New to Feedback
Actions #5

Updated by Vladimir Lind about 3 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.

Actions #6

Updated by A FL about 3 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...

Actions #7

Updated by Jim Pingle almost 3 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.

Actions

Also available in: Atom PDF