1 User Per Voucher Code
-
Did you try checking this?
Concurrent user logins Disable concurrent logins
If this option is set, only the most recent login per username will be active. Subsequent logins will cause machines previously logged in with the same username to be disconnected. -
Thanks for answering Derelict, Yes i have checked this option and the same problem any other solution ?
-
Try my solution in this thread:
https://forum.pfsense.org/index.php?topic=107309.0Im unsure if it works, but it looks like it should work.
If it don't work, set up a custom authentication page that will, in addition to allowing the user in, also mark the voucher as "spent".
-
It works.
-
Thanks sebastiannielsen, but this solution wont let me change the voucher time so all vouchers will be expired after "Hard timeout" period i just wanted to make vouchers with various amount of times
so isn't there any other solution ?? -
i found this solution but idk how to apply it
https://forum.pfsense.org/index.php?topic=43100.0 -
i found this solution but idk how to apply it
https://forum.pfsense.org/index.php?topic=43100.0So, found an old using solution that worked for an ancient pfSense version, instead of the proposed -recent- one ….
Why ? What is the logic ? -
Then its only one solution left:
Recode the voucher login page to "spend" each voucher code after use.To do this, create a login page, that will submit the voucher code to lets say captiveportal-spend.php
on "File manager", create a script captiveportal-spend.php, that will check against a list of valid voucher codes, and then delete the voucher code from that list. This could be as simple as a list of sha256 hashes of valid voucher codes in the webroot of captive portal, and the script simply deletes the hash of each voucher code when it finds a valid one.
When the script finds a valid hash, it will output a javascript form, that will autosubmit to the $PORTAL_ACTION$ url.To increase security, you could have 2 sets of 64 bit keypairs, where you will generate 2 sets of vouchers containing the exact same numbers, just different keys.
So in the script captiveportal-spend.php, check against the sha256 hashes in file, and if a match is found, voucher is deleted from that file, then you decrypt the voucher using the first public key, and then you encrypt, but now with the private key found in the voucher settings, and create a autosubmit form for this.Eg, in the captive portal settings for vouchers, you have keypair B set up.
So on the receipt, you print the voucher like "V78E2Q", that is created using the private key of pair A.
Then user enter it on login page.
Gets sent to captiveporta-spend.php. captiveportal-spend.php checks in sha256 file if voucher exist. If yes, then delete the hash and continue. If no, display error message that voucher has been spent.
captiveportal-spend.php DECRYPT voucher using public key of pair A, rendering a magic number + ticket ID + roll ID and checksum. Then captiveportal-spend.php ENCRYPT using the private key of pair B.
Then it creates a autosubmit page to the real $PORTAL_ACTION$ containing this voucher code.Of course, this is not rock solid security, as anyone that would listen in the communication, eg with a client-side listening software, or with web developer tools not following redirects, could capture the final form and use the final "multiple-use-code". But such a techny-savy user could hack the system in other ways like spoofing mac/ip or even use internet sharing and such.
But this would atleast make it significantly harder to use the same voucher code for multiple devices.
-
….
Of course, this is not rock solid security, as anyone that would listen in the communication, eg with a client-side listening software, or with web developer tools not following redirects, could capture the final form and use the final "multiple-use-code". But such a techny-savy user could hack the system in other ways like spoofing mac/ip or even use internet sharing and such.To lower this risque, activate https option for the captive portal (you'll be needing domain name - and a free, but valid and recognized certificate from startssl.com (or others))
-
Gertjan: As I said, the listening is then done on client side, so HTTPS would not harden it so much, since the user could use wget or any other HTTPS capable client to do the authentication.
But to further even increase security, you could use a captcha and even javascript code that will ensure a real functioning browser, along with HTTPS. Then it will be a tough nut to crack.
-
@gertjan how do you upload or install this patch on the Pfsense that's these "1 User Per Voucher Code"?
-
@sanctify said in 1 User Per Voucher Code:
@gertjan how do you upload or install this patch on the Pfsense that's these "1 User Per Voucher Code"?
That question was valid in 2016, that's 5 years ago.
These days, you select :
