Project

General

Profile

Bug #3441

Non-alphanumeric characters cause issues with Captive Portal

Added by Doktor Notor over 7 years ago. Updated over 7 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Captive Portal
Target version:
2.1.1
Start date:
02/08/2014
Due date:
% Done:

100%

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

Description

On trying to enter a message with diacritics (e.g. ěščřžýáíéúů) on a CP Zone - Vouchers - Invalid Voucher Message/Expired Voucher Message, as soon as I hit Save, I get "pfSense is restoring the configuration /cf/conf/backup..." message.

BTW, this input validation bug has been mentioned with voucher rolls on the forum 1 1/2 year ago, I have not tested whether it's fixed or not.

Associated revisions

Revision bd369bcf (diff)
Added by Ermal Luçi over 7 years ago

Use descr as the field name for voucher description so it gets CDATA protection. Fixes #3441

Revision 378296af (diff)
Added by Ermal Luçi over 7 years ago

Use descr as the field name for voucher description so it gets CDATA protection. Fixes #3441

Revision ec96f17d (diff)
Added by Ermal Luçi over 7 years ago

Provide upgrade code after changes done for Ticket #3441

Revision eae91304 (diff)
Added by Ermal Luçi over 7 years ago

Merge 10 -> 10.1 and 10.1 -> 10.2 function upgrade since the recent changes done on 2.1.1 for Ticket #3441

Revision 1274cfd4 (diff)
Added by Ermal Luçi over 7 years ago

Use descr prepended to voucher fields containing descriptions to have them encoded as CDATA. Fixes #3441

Revision f3f04169 (diff)
Added by Ermal Luçi over 7 years ago

Use descr prepended to voucher fields containing descriptions to have them encoded as CDATA. Fixes #3441

Revision 20dad315 (diff)
Added by Ermal Luçi over 7 years ago

Provide upgrade code after changes done for Ticket #3441

History

#1 Updated by Doktor Notor over 7 years ago

#2 Updated by Ermal Luçi over 7 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#3 Updated by Ermal Luçi over 7 years ago

#4 Updated by Chris Buechler over 7 years ago

  • Status changed from Feedback to Resolved

#5 Updated by Doktor Notor over 7 years ago

This did not work, sorry. Still getting the same problem with Mar 7 snapshot.

#6 Updated by Doktor Notor over 7 years ago

Looks like you fixed the voucher rolls comment issue, but not the Invalid Voucher Message/Expired Voucher Message ones.

#7 Updated by Doktor Notor over 7 years ago

Please, reopen this, the issue reported here is not fixed.

#8 Updated by Renato Botelho over 7 years ago

  • Status changed from Resolved to New

#9 Updated by Ermal Luçi over 7 years ago

Can you give information from your system?
/tmp/PHP_errors.log etc....

#10 Updated by Ermal Luçi over 7 years ago

  • Status changed from New to Feedback

#11 Updated by Ermal Luçi over 7 years ago

#12 Updated by Doktor Notor over 7 years ago

Sorry, this is STILL broken with Sat Mar 15 02:43:41 EDT 2014 snapshot. Nothing relevant in /tmp/PHP_errors.log. nanobsd on Alix.

#13 Updated by Doktor Notor over 7 years ago

The only relevant thing logged is this:

Mar 15 23:04:59    php: /services_captiveportal_vouchers.php: XML error: Invalid character at line 4619 in /conf/config.xml

#14 Updated by Doktor Notor over 7 years ago

Also looks like the Invalid Voucher Message/Expired Voucher Message stopped syncing with the master...

#15 Updated by Renato Botelho over 7 years ago

  • Status changed from Feedback to New

Doktor Notor wrote:

The only relevant thing logged is this:

[...]

Could you share content of this line? and possibly a context of 5 lines above and below.

#16 Updated by Doktor Notor over 7 years ago

Well, this line is the closing tag:

</voucher>

Obviously not logging the relevant line where the issue really happens.

#17 Updated by Doktor Notor over 7 years ago

I tried again on another box. Still, the same issue.

Mar 17 15:20:06    php: /services_captiveportal_vouchers.php: pfSense is restoring the configuration /cf/conf/backup/config-1395064499.xml
Mar 17 15:20:05    php: /services_captiveportal_vouchers.php: XML error: Invalid character at line 4744 in /conf/config.xml

I don't know what to post here, since obviously the offending lines are gone and restored to previous state, which is:

4742                         </roll>
4743                         <descrmsgnoaccess><![CDATA[Neplatny voucher / Voucher invalid]]></descrmsgnoaccess>
4744                         <descrmsgexpired><![CDATA[Platnost voucheru vyprsela / Voucher expired]]></descrmsgexpired>
4745                 </hotel_wlan_zone>
4746         </voucher>

#18 Updated by Warren Baker over 7 years ago

Doktor Notor wrote:

I don't know what to post here, since obviously the offending lines are gone and restored to previous state, which is:

There should be a config.xml.bad file in /conf which contains the invalid characters.

#19 Updated by Doktor Notor over 7 years ago

@Warren: Ah... Well, looks pretty clear now. Obvious crap there.

4742                         </roll>
4743                         <descrmsgnoaccess><![CDATA[Neplatn&yacute; voucher / Voucher invalid]]></descrmsgnoaccess>
4744                         <descrmsgexpired><![CDATA[Platnost voucheru vypr<9A>ela / Voucher expired]]></descrmsgexpired>

The <9A> is supposed to be š AFAICT - i.e. letter "š"

#20 Updated by Doktor Notor over 7 years ago

Christ, this Redmine thing sucks...

The <9A> is supposed to be &scaron; AFAICT - i.e. letter "š"

#21 Updated by Renato Botelho over 7 years ago

  • Status changed from New to Feedback

It happens because the char is not part of ISO-8859-1, and all pages on pfSense use this encoding. If you insert the same char on a Firewall -> Rule description for example, the same error will happen. The issue with captive portal is fixed since it's not accepting non-alphanumeric chars. It's a different issue, a new bug should be filled in order to change it for all fields that accepts non-alphanumeric chars. It won't be fixed before 2.1.1 since it's probably a big change.

#22 Updated by Doktor Notor over 7 years ago

ISO-8859-1? In 2014? Oh well... forget this bug report.

#23 Updated by Doktor Notor over 7 years ago

Oh, one last thing, definitely "change it for all fields that accepts non-alphanumeric chars" is something that definitely should NOT ever be done, since the only real bug here is that this thing uses Latin-1 instead of Unicode... So no, a bug like that - that's not something I'd ever file.

P.S. Thanks for the debugging time!

#24 Updated by Renato Botelho over 7 years ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF