Bug #117767 for Authen-SASL-SASLprep: Please add 'stored strings' capability

Sat Sep 10 19:34:48 2016 dagolden [...] cpan.org - Ticket created

Subject:

Please add 'stored strings' capability

Currently, Authen::SASL::SASLprep doesn't pass an "unassigned_check" argument to Unicode::Stringprep. This means it's in "query string" mode, which allows unassigned characters. For usernames/passwords, it might be more appropriate to be using "stored strings" mode. (See https://tools.ietf.org/html/rfc3454#section-7 for differences.) Could you please add a feature to do stored mode? Possibly, just a boolean second parameter. Thank you.

Tue Sep 13 16:01:11 2016 CFAERBER [...] cpan.org - Correspondence added

Thanks for your input. I think that it might best be implemented in Unicode::Stringprep. It's strange that it never occurred to me to implement it there, even though it's required by Net::IDN::Nameprep.

Tue Sep 13 16:01:11 2016 The RT System itself - Status changed from 'new' to 'open'

Tue Sep 13 16:02:42 2016 CFAERBER [...] cpan.org - Taken

Tue Sep 13 21:12:23 2016 dagolden [...] cpan.org - Correspondence added

On Tue Sep 13 16:01:11 2016, CFAERBER wrote: Show quoted text

> Thanks for your input. I think that it might best be implemented in > Unicode::Stringprep. It's strange that it never occurred to me to > implement it there, even though it's required by Net::IDN::Nameprep.

I think it may already be implemented: https://metacpan.org/source/CFAERBER/Unicode-Stringprep-1.105/lib/Unicode/Stringprep.pm#L39 I'm not sure that achieves all the right semantics, but it seems close. The problem with Authen::SASL::SASLprep that I'm raising with this bug is that there's no way to set that argument. Something like: saslprep($input, $use_stored_mode);

Sat Sep 24 05:56:19 2016 CFAERBER [...] cpan.org - Correspondence added

Yes, U::S does implement stored strings. However, it currently only returns a closure with all parameters baked in. You cannot, currently, select stored and query strings on a per-case basis.

Sun Sep 25 18:30:45 2016 CFAERBER [...] cpan.org - Correspondence added

I've implemented stored strings in version 1.100. This uses the same workaround as Net::IDN::IDNA2003 to work around Unicode::Stringprep's limitation (just create two separate functions/closures). This is not very efficient but I think that the best idea is to make Unicode::Stringprep more efficient if it is used multiple times with (partially) the same parameters.

Sun Sep 25 18:31:12 2016 CFAERBER [...] cpan.org - Severity Wishlist added

Sun Sep 25 18:31:12 2016 CFAERBER [...] cpan.org - Broken in 1.00 added

Sun Sep 25 18:31:12 2016 CFAERBER [...] cpan.org - Broken in 1.01 added

Sun Sep 25 18:31:12 2016 CFAERBER [...] cpan.org - Broken in 1.011 added

Sun Sep 25 18:31:12 2016 CFAERBER [...] cpan.org - Broken in 1.100 added

Sun Sep 25 18:31:12 2016 CFAERBER [...] cpan.org - Status changed from 'open' to 'patched'

Mon Sep 26 09:20:45 2016 dagolden [...] cpan.org - Correspondence added

Thank you! I think that's workable solution. Personally, I would make _saslprep_stored and _saslprep_query into lexical variables to keep them encapsulated, but that's your call. If you're concerned about the extra subroutine call overhead, I would just provide and export saslprep_query and saslprep_stored as separate subs and either have saslprep route between them or else have it just be an alias for saslprep_query. I.e. *saslprep_stored = Unicode::Stringprep->new( ... ); *saslprep_query = Unicode::Stringprep->new( ... ); *saslprep = \&saslprep_query;