-
-
Notifications
You must be signed in to change notification settings - Fork 227
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
Define value constraint using regular expressions #1417
Conversation
@SemanticMediaWiki/testers I'd appreciate if this finds some love amongst testers to give it a run down. |
Cool! Edit:
|
Tested. It seems fine to me. 👍 |
As listed in [0], " The regex modifier If users feel more comfortable we can ship this as an opt-in rather than an opt-out by removing the [0] https://www.semantic-mediawiki.org/wiki/Help:Special_property_Allows_pattern |
I don't remember the details of the concerns @Benestar mentioned, though have a vague notation that it was DoS by means of resource consumption. |
Related ticket can be found here: https://phabricator.wikimedia.org/T105126 |
Also relevant and linked from the ticket: http://www.regular-expressions.info/catastrophic.html |
Thanks
I did a quick read through and with "... about this for months now and it seems there is no solution. Either have regular expressions or not.", I concur that I want regex support but I also recognize the potential impact therefore I've decided (just made a rough prototype) to add an administrative level. Instead of allowing to add a pattern directly, the property expects a reference (as shown below) with the actual regex being maintained in [0] https://www.mediawiki.org/wiki/Manual:$wgNamespaceProtection |
Similar to `Allows value`, the `Allows pattern` property is to specify a regular expression to match permissible values for an assigned property. If a value cannot be matched then a general purpose message is being displayed. To avoid any issues with expressions that include | or [] it is suggested to use #set (`|+pipe` indicator ensures that MW doesn't interfere with the expression): ``` Whitelist {{#set: |Allows pattern=^(Foo|Foo bar|Bar)$|+pipe }} ``` ``` IPv4 {{#set: |Al1lows pattern=(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])$|+pipe }} ``` `$GLOBALS['smwgDVFeatures'] = SMW_DV_PAVP` is enabled by default but if removed will disable the functionality.
Over the weekend, I was elaborating on the approach and as indicated above, regular expression declaration has been moved to one dedicated place Not enough that the property @kghbln FYI, PR comes with a new group/right ( [0] https://www.semantic-mediawiki.org/wiki/Help:Permissions_and_user_rights |
Define value constraint using regular expressions
Speaking of permission, @kghbln would you mind assigning the curator group to me so I can create an example. |
@mwjames Not at all and this is done now. Great to see that my setup works as indented. |
@JeroenDeDauw So far you do not have an account on sandbox. Shame on you and currently not extra rights! ;) |
👍 |
Cool, will try to add patterns for IBAN DE, AT and CH |
All one needs for IBANs including ref! |
Suppress error on regex compilation, refs #1417
PatternConstraint to escape early, refs #1417
Are there more than one "Allows pattern" assignments possible per property? I would guess yes. |
Yes BUT only the last will win [0]. |
This saves a lot of headaches as we don't have to make assumptions. Regular expressions are very "stretchy", so for those who want to combine different patterns, create a new reference, merge them in a coherent way leaving SMW to not second guess the intend. |
Thanks for the info. Indeed this makes much sense. This is now documented. |
Similar to
Allows value
, theAllows pattern
property is to specify a regular expression to match permissible values for an assigned property. If a value cannot be matched then a general purpose message is being displayed.$GLOBALS['smwgDVFeatures'] = SMW_DV_PAVP
is enabled by default but if removed will disable the functionality