Project

General

Profile

Bug #9114

Captive Portal Blocked MAC Address Redirect URL not working

Added by Keith Anderson 4 months ago. Updated 4 months ago.

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

0%

Estimated time:
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

example.jpg (49.3 KB) example.jpg Keith Anderson, 11/13/2018 06:33 AM

Associated revisions

Revision 83a6f504 (diff)
Added by A FL 4 months ago

Redirect Blocked MAC without requiring credentials if Blocked MAC URL has been entered.

Redmine #9114

Revision 5225415a (diff)
Added by A FL 4 months ago

Redirect Blocked MAC without requiring credentials if Blocked MAC URL has been entered.

Redmine #9114

(cherry picked from commit 83a6f504d6eb4d1925c4745a6457805fbbe308d9)

History

#1 Updated by A FL 4 months 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.

#2 Updated by Keith Anderson 4 months 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.

#3 Updated by Renato Botelho 4 months ago

  • Assignee set to Renato Botelho
  • Target version set to 2.4.4_1

PR merged. Thanks

#4 Updated by Renato Botelho 4 months ago

  • Status changed from New to Feedback

#5 Updated by Vladimir Lind 4 months 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.

#6 Updated by A FL 4 months 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...

#7 Updated by Jim Pingle 4 months 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.

Also available in: Atom PDF