parsley.jsparsley

Data-parsley-pattern Regex Failing After Upgrade to 2.8


We have a small portal application for our customers which allows them to specify a directory they wish to have backed up. While we have robust checks to block bad behaviour on the back end, we'd like to prevent them from typing ".." as part of the path name in the submitted form.

Specifically the first example would be allowed. The other examples would be rejected by the form validation.

web/wordpress.sitefiles/ ../../../etc/somefile web/../../../etc/somefile web/badname../

Previously we were using

data-parsley-pattern = '(?![\.]{2})'

which seemed to do the job nicely.

I'm not sure I understand the regex changes with Parsley 2.8. Now literally nothing will validate in our form..

I have reviewed the Parsley documentation and searched StackOverflow and other online sources to no avail.

Using regextester.com as a sandbox, the following pattern does exactly what we need.

'^((?![.]{2}).)*$'

However that doesn't seem to translate well to a data-parsley-pattern. In our form, the above regex matches anything we type in.

It mentions in the docs that regex patterns are now anchored, so I also tried a reduced version of

'((?![.]{2}).)*'

But that matches everything as well.

This seemed to be such a simple problem, but I think my limited knowledge of regex is leading me astray or causing me to misunderstand the Parsley docs.

Any guidance would be greatly appreciated.


Solution

  • So, the error was not in my regex, but my understanding of how Parsley responds to forms after an unsuccessful submission.

    I think its actually a minor bug, but perhaps the behaviour is by design.

    I have a form with 5 inputs. The first two are pre-filled with defaults. The third is blank and the last two are integer, min value 1, pre-filled with "0".

    The second input is the text field where we are disallowing "..". It is pre-filled with the value "web/".

    If you try to submit the form without modifying the content after the page loads, the top two fields show green, the third is empty and the bottom two integers are flagged red.

    Now, if you change "web/" in the second box to "web/.." the field stays green. It's not alerting to the invalid match.

    If you change the red integers to a valid range, they turn green and then red if you change them to an invalid number.

    It seems that ONLY if I hit the submit button with an invalid value in the "web/" field, does that field start dynamically reporting as I change the string to valid/invalid values.

    Of course, if I hit SUBMIT, it validates properly on all fields. So my error was relying on the field colour to test my regex.