-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
generating password string from specific Rule does not function #65
Comments
Just to clarify few things: This is Specific version is: I have also tried playing around with settings (specificly Perfect solution for me would be - using same regex for checking, and for generating the passwords. But in case this issue is "solvable" with just adding custom regexp, used for generating the password - I'm fine wht that too :) And - yes, apologies, I'm not that good with regexps in general, so I might be overlooking obvious things here. Sorry :) |
Atm "solved" the issue by re-generating password... For the reference, my working code:
I guess it can be used as a pseudocode, if somebody would need it. Checking with |
Hello! Thank you for reaching out and reporting this issue. The long story short - the problem is that it is quite hard at the moment to handle situation when lookbehind/lookahead should influence/limit possible variations of other parts of expression. From my current view your case is particularly complex. And most probably will be solved (if I will not find any nicer approach), by just brute-force:
Let's keep this ticket open for now and I will think about the solution for this and the previously mentioned ticket, though I don't want to promise that the solution will be in a nearest time available. I will need to think more about approaching this issue, but most probably I will have quite limited solution with a brute-force approach and some configuration options to fine-tune the process. In the meantime - regarding your solution:The approach you've taken works only by a miracle. The fact is that it currently works as follows:
This is obviously incorrect approach and the results are also only occasionally might be valid. There are few ways I see how you can improve this: Java test:
This tricks RgxGen with the fact, that each alternative has equal probability to be selected for each character generation. Hope that helps. :) |
Good day :) Ok, then let's hope this will get resolved with the version, that will contain that #63 fix :) Meanwhile, my 5 cents on your latest comment: First of all I totally understand that this is a really complicated case of regex for Then, about your last comment.
First of all - thank you very much for this new RegEx. It works properly for generating, and validating passwords, both way :) But anyways, it does bring a benefit of using single regex for both generator, and validator, which simplifies things on my end a lot :)
I can speak for myself at least - this would be good enough approach for me, because then I would just rely on the Library to deliver a password, without taking care of these extra checks and complexities. Thank you very much for your product sir, and I wish you best of luck! |
That is very strange that you say it provides same rate of errors. Please check it once again. Because for me it can generate 1000 values without a single one failing in a row. I'm not sure how do you check pattern in Scala, but in Java there are 2 methods:
For this code:
I get output like: true W6qI62wg3OICn4 Process finished with exit code 0 |
can confirm Adapted Pattern as described above works like a charm if you use Java |
Describe the bug
Consider a common use-case:
We have a regex, used to validate a "password" string.
F.e.
^(?=.*[A-Z])(?=.*[!@#$&*])(?=.*[0-9])(?=.*[a-z])[A-Za-z0-9@$!*#&]{8,25}$
Limits:
!@#$&*
)Then, if we try to feed it to the library, and afterwards generate a password, we are getting passwords which are
F.e.
7'lP|EyCt"S*00?]7A,<(hhjkR9u82v$!TnIs$$RG*x
, or+~WioK%R#6=6IU]r23Y@Zm&GN@#!6nH3ng1s0&vH4
.THen, for the sake of experiment, if we would consider simplifying the workflow by introducing another pattern, which would be used only for
generating the password
, with something more simple, like that:^[A-Za-z0-9@$!*#&]{8,25}$
- we do actually get proper passwords generated, but not every time.As this regex does not qualify any occurrence-times-per-group restrictions, only the overall pattern - generated password might have inclusions from all groups, or might not have...
F.e.
7GgDIEFsD
,lZcYX6IpgGwOMOO5vQD#pT
.Both generated from single run, using simplified regex.
Honestly - I have no ideas of how to tackle this issue nicely, and any advisory/workaround would be as welcomed as the fix.
To Reproduce
Steps to reproduce the behavior:
^(?=.*[A-Z])(?=.*[!@#$&*])(?=.*[0-9])(?=.*[a-z])[A-Za-z0-9@$!*#&]{8,25}$
Semantic: Generated string does not match the regex restrictions.
Expected behavior
Generated string would follow original Regex restrictions.
Environment (please complete the following information):
Ubuntu 20.10
JDK 8
Latest.
The text was updated successfully, but these errors were encountered: