regex substitution problem

[Dave Saville]

I have had a good look around and can't find the solution to a problem I have.

CGI script processing ID/password. I have a file of all the ID/Passwords.

I was checking by a foreach down the file with

if ( m/$id $pwd/ ) {.........}

it being a space separator in the file. This worked fine until someone had a
password with a ( in it. Whereupon perl chokes on the (.

Now I know you can get around this in a replace as in s'$foo'$bar' but how can
you do it for a match?

TIA

And before someone says RTFM I don't actually know what it is I would be
looking for in terms of what functionality I want to suppress



--

Regards

Dave Saville

NB Remove -nospam for good email address

 

[Paul Lalli]

I have had a good look around and can't find the solution to a problem I have.

CGI script processing ID/password. I have a file of all the ID/Passwords.

I was checking by a foreach down the file with

if ( m/$id $pwd/ ) {.........}

it being a space separator in the file. This worked fine until someone had a
password with a ( in it. Whereupon perl chokes on the (.

Now I know you can get around this in a replace as in s'$foo'$bar' but how can
you do it for a match?

perldoc -f quotemeta
perldoc perlop
(search for \Q)

if ( m/\Q$id\E \Q$pwd\E/ ) { ... }

And before someone says RTFM I don't actually know what it is I would be
looking for in terms of what functionality I want to suppress

Honestly, in this case, I probably wouldn't either. I'd probably
start out on one of the three regexp pages, though. And indeed, I just
confirmed that
perldoc perlre
has the following snippet:

======================================================
Backslashed metacharacters in Perl are alphanumeric, such as \b , \w ,
\n . Unlike some other regular expression languages, there are no
backslashed symbols that aren't alphanumeric. So anything that looks
like \\, \(, \), \<, \>, \{, or \} is always interpreted as a literal
character, not a metacharacter. This was once used in a common idiom to
disable or quote the special meanings of regular expression
metacharacters in a string that you want to use for a pattern. Simply
quote all non-"word" characters:

$pattern =~ s/(\W)/\\$1/g;

(If use locale is set, then this depends on the current locale.) Today
it is more common to use the quotemeta() function or the \Q metaquoting
escape sequence to disable all metacharacters' special meanings like
this:

/$unquoted\Q$quoted\E$unquoted/
======================================================

Paul Lalli

 

[it_says_BALLS_on_your forehead]

I have had a good look around and can't find the solution to a problem I have.

CGI script processing ID/password. I have a file of all the ID/Passwords.

I was checking by a foreach down the file with

if ( m/$id $pwd/ ) {.........}

it being a space separator in the file. This worked fine until someone had a
password with a ( in it. Whereupon perl chokes on the (.

Now I know you can get around this in a replace as in s'$foo'$bar' but how can
you do it for a match?

you could do javascript form validation for this, or you could check to
make sure that only valid characters are present in Perl by checking to
see that the values only contain word characters (i.e. \w).

 

[Paul Lalli]

you could do javascript form validation for this,

....unless the user has disabled javascript or a sneaky user decides to
execute the CGI script without using the form at all. Javascript
validation is a convenience, not a solution.

or you could check to
make sure that only valid characters are present in Perl by checking to
see that the values only contain word characters (i.e. \w).

No no no. The user is 100% in choosing a password that has non-"word"
characters in it. Far harder to crack or guess.

There is no reason to "pre-validate" the passwords at all. Let the
user choose whatever he/she damned well pleases. Simply tell Perl that
this variable contains plain text, not regular expression characters.

perldoc -f quotemeta, as I said in my last response to this thread.

Paul Lalli

 

[it_says_BALLS_on_your forehead]

...unless the user has disabled javascript or a sneaky user decides to
execute the CGI script without using the form at all. Javascript
validation is a convenience, not a solution.


No no no. The user is 100% in choosing a password that has non-"word"
characters in it. Far harder to crack or guess.
true.


There is no reason to "pre-validate" the passwords at all. Let the
user choose whatever he/she damned well pleases. Simply tell Perl that
this variable contains plain text, not regular expression characters.

however, what about compatibility across all levels of the app? backend
included. i know that you can quote characters in the DB, so that
single quotes won't break entries, but there may be many other things
which have assumptions about what characters are valid and which
aren't. the OP needs to be certain that by allowing 'weird' characters,
he's not breaking something downstream.

just something to consider. i'm not advocating shying away from a
problem just because it's difficult, but just cautioning the OP to be
aware that there exist dependencies.

 

[Dave Saville]

Thanks guys. You learn something new every day.

Now what was it I learnt yesterday?

--

Regards

Dave Saville

NB Remove -nospam for good email address

 

[Josef Moellers]

Thanks guys. You learn something new every day.

Now what was it I learnt yesterday?

Perhaps quoting some context when replying?