Project

General

Profile

Actions

Bug #14325

closed

Captive Portal incorrectly allows leading zeroes on voucher roll numbers

Added by Lev Prokofev 12 months ago. Updated 6 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Captive Portal
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
23.09
Release Notes:
Default
Affected Version:
Affected Architecture:

Description

If you will create the Voucher roll with the number "000" or "0001" the system will allow you to create a such roll, but the Vouchers from this list will be not valid and the end user will be not able to authorized in the CP. Lists without zeros are working as expected.



Files

clipboard-202304291110-ushq7.png (21.2 KB) clipboard-202304291110-ushq7.png Lev Prokofev, 04/29/2023 07:10 AM
clipboard-202304291112-rzpvf.png (34.5 KB) clipboard-202304291112-rzpvf.png Lev Prokofev, 04/29/2023 07:12 AM
clipboard-202309240909-0sqae.png (24.9 KB) clipboard-202309240909-0sqae.png aleksei prokofiev, 09/24/2023 06:09 AM
clipboard-202309240910-bmpvq.png (11.3 KB) clipboard-202309240910-bmpvq.png aleksei prokofiev, 09/24/2023 06:10 AM
Actions #1

Updated by aleksei prokofiev 12 months ago

I've tested on 23.01 and can confirm that.

Actions #2

Updated by Kris Phillips 10 months ago

Tested and confirm behavior in pfSense CE 2.7.

Actions #3

Updated by aleksei prokofiev 9 months ago

Checked, I confirm this behavior on 23.05.1 as well.
23.05.1-RELEASE (amd64)
built on Wed Jun 28 03:57:27 UTC 2023
FreeBSD 14.0-CURRENT

Actions #4

Updated by aleksei prokofiev 7 months ago

Tested on
23.09-DEVELOPMENT (amd64)
built on 20230922-1539
FreeBSD 14.0-CURRENT

The issue still persists, if the voucher has zeros you will get next message when test voucher

Actions #5

Updated by Jim Pingle 7 months ago

  • Status changed from New to In Progress
  • Assignee set to Jim Pingle
  • Target version set to 2.8.0
  • Plus Target Version set to 23.09

The underlying voucher binary strips leading zeroes so we should strip them when creating rolls as well (use intval() for example).

The input validation code already makes sure you can't create overlapping rolls such as 22 and 00022, so it should be safe to also trim the number on the backend.

Actions #6

Updated by Jim Pingle 7 months ago

Fixing the backend or doing upgrade code seemed like overkill since there is no way these worked before. I fixed the edit screen to use the integer value of the roll number. So if you edit one of these and save it will be OK as-is. The generated vouchers for roll 22 are the same as 00022 for example so there is no need to worry about generated voucher codes not being valid.

Actions #7

Updated by Jim Pingle 7 months ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100
Actions #8

Updated by Jim Pingle 7 months ago

  • Status changed from Feedback to Resolved

Current snapshot uses the integer value as it should, no more leading zeroes in the roll number after saving.

Actions #9

Updated by Jim Pingle 7 months ago

  • Subject changed from Voucher page of Captive portal doesn't properly validate the roll number to Captive Portal incorrectly allows leading zeroes on voucher roll numbers

Updating subject for release notes.

Actions #10

Updated by Jim Pingle 6 months ago

  • Target version changed from 2.8.0 to 2.7.1
Actions

Also available in: Atom PDF