Add support for specifying an arbitrary token pattern

[xfbs]

Hey!

This looks really cool, I love that you wrote this in Rust!

I have a quick idea for you. I'm the author of passgen, and the idea behind that is that you can specify an arbitrary pattern, as a regular expression. So, for example instead of having some preset patterns (ascii-lower-32, uuid-v4, ip-127), it could take a regular expression. For example (these are slightly wrong, I know):

• ascii-lower-32 could be represented as [a-z]{32},
• uuid-v4 could be represented as [0-9a-f]{8}-([0-9a-f]{4}-){3}[0-9a-f]{12}
• ip-127 could be represented as 127.[0-9]{3}.[0-9]{3}.[0-9]{3}

I think this is a cool feature and I'd be happy if z-tokens could do this too!

Cheers,
-Patrick

[cipriancraciun]

Thanks for the interest! (I'll take a look at passgen to see what other ideas I could "steal" from there.) :)

So, about the arbitrary token pattern, technically it is possible without much effort, as the patterns are actually modeled as a abstract syntax tree (see the model.rs file, especially TokenPattern, at https://github.com/volution/z-tokens/blob/development/sources/model.rs#L41).

There is the need for the regex-like syntax parser that would yield such TokenPattern instances. And I assume implementing this wouldn't be too complicated.

However, at the moment I would like to focus on some other aspects of the tool, and leave this for later.

---

On the other hand, from an usability point of view, I think the best approach is to identify common, or useful, or "best-practice", patterns and just provide custom patterns for them.

---

Moreover, there are also a few other concerns that don't quite fit with the regex-like patterns:

• for example my ip-10 pattern would never generate anything that has a 0..1 or a 254..255 in any of the bytes, because these are most likely used for broadcast / network or router; thus strictly speaking ip-10 would generate less than the syntactically correct IP addresses, by making sure they aren't "usually" invalid for the common case;
• there is also the issue of performance; for example the components of the UUID are not defined in z-tokens as a sequence of n hex characters, but as a random integer (in the proper range); (the same for a few other patterns;)

Thus, even if I were to implement such a regex-like pattern, I would also need to take into account the fact that my token model is more complex than just characters.

[xfbs]

I understand, maybe it does not fully make sense for this project. At least I wanted to communicate the idea to you. As someone who maintains a random pattern generator, I'm always curious to see the ideas that others have and how they have built it. You can learn so much.

Btw, possibly off-topic, but: how do the scripts in the scripts folder work? I noticed that you seem to be doing some amount of code autogeneration (looks like there is a bunch of whitespace in the sources, too) but I haven't been able to make sense of how it ties together?

Cheers,
Patrick

[cipriancraciun]

I understand, maybe it does not fully make sense for this project. At least I wanted to communicate the idea to you. As someone who maintains a random pattern generator, I'm always curious to see the ideas that others have and how they have built it. You can learn so much.

Please don't hesitate to open other issues / feature requests, now or in the future if you get other ideas.

In essence I wanted to make this project a "catch-all" for all the "sensible" password / passphrases generation techniques.

---

With regard to the regex-like issue, I'll leave it open and implement it when I have some time.

This also ties with #2, allowing one to customize the length of a token.