CAN-DO Function

Posted by Ham on 04-Mar-2014 05:20

Once upon a time the CAN-DO function was "misused" to do string pattern checking. A sort of poor man's regex. But, it was documented so that made it ok.

From 10.2 documentation:
CAN-DO ( id-list [ , string ] )
[snip]
In addition to performing security checks, you can use the CAN-DO function for looking up any
value in a comma-separated list. For example, the following procedure searches your PROPATH
for your DLC directory:
MESSAGE "The DLC directory " +
(IF CAN-DO(PROPATH, OS-GETENV("DLC")) THEN "is" ELSE "is NOT") +
" in your PROPATH.".
[snip]
That same example code now breaks in V11!
Where can-do function has been "declassed" as only security checking against userid:
CAN-DO ( id-pattern-list [ , userid ] )
Did anyone notice?
Got angry?
Had to write it's own CAN-DO function?
Please share!
Ciao,
Wim

All Replies

Posted by James Palmer on 04-Mar-2014 05:43

CAN-DO always had unpredictable results as it was never designed for pattern checking. Thankfully it's simple to change it to LOOKUP. All you need is to swap the arguments around.

Posted by jmls on 04-Mar-2014 05:43

I believe that it got "broken" because of multi-tenant.

can-do was *always* only to be used for security checking. Despite
what the docs and examples say ;)

see https://community.progress.com/technicalusers/f/19/p/1630/6874.aspx#6874

Julian

On 4 March 2014 11:21, Ham wrote:
> CAN-DO Function
> Thread created by Ham
>
> Once upon a time the CAN-DO function was "misused" to do string pattern
> checking. A sort of poor man's regex. But, it was documented so that made it
> ok.
>
> From 10.2 documetation:
> CAN-DO ( id-list [ , string ] )
> [snip]
> In addition to performing security checks, you can use the CAN-DO function
> for looking up any
> value in a comma-separated list. For example, the following procedure
> searches your PROPATH
> for your DLC directory:
> MESSAGE "The DLC directory " +
> (IF CAN-DO(PROPATH, OS-GETENV("DLC")) THEN "is" ELSE "is NOT") +
> " in your PROPATH.".
> [snip]
> That same example code now breaks in V11!
> Where can-do function has been "declassed" as only security checking against
> userid:
> CAN-DO ( id-pattern-list [ , userid ] )
> Did anyone notice?
> Got angry?
> Had to write it's own CAN-DO function?
> Please share!
> Ciao,
> Wim
> Stop receiving emails on this subject.
>
> Flag this post as spam/abuse.



--
Julian Lyndon-Smith
IT Director,
dot.r
http://www.dotr.com

"The bitterness of poor quality remains long after the sweetness of
low price is forgotten"

Follow dot.r on http://twitter.com/DotRlimited

Posted by Thomas Mercer-Hursh on 04-Mar-2014 09:27

CAN-DO functions as it always has with one exception and that is the addition of @ to the list of magic characters ... as Julian says, to support multi-tenant.  Unfortunately, that has uncovered some abusive uses. :)

Posted by Ham on 04-Mar-2014 09:36

Not exactly :-(

CAN-DO had also simple pattern checking, including special characters like ! for NOT and * as a wildcard. Lookup won't do that. I'm afraid a User defined function is the only way to replace CAN-DO with something that also works in V11.

Posted by James Palmer on 04-Mar-2014 09:41

Fair enough. Although, technically, you should have been using your own function in earlier releases too ;)

Posted by Rob Fitzpatrick on 04-Mar-2014 12:51

I agree with Wim, Etienne, et al.  Progress customers got burned by bad documentation in 10.x and earlier.  If the Progress documentation for a function says, release after release, that you can use it for a use-case other than userid permission-checking then that's a valid use case, full stop.

Code that implements such use cases is not "abusive".  It is not code that "should not" have been written.  That's just insulting.

Product documentation tells you what a feature does and, hopefully, how it should or should not be used.  If it tells you you can do something with a function then you can.  Later versions of the documentation can't just come along later and effectively say "why did you do that, idiot?"

I don't care what is said to the contrary in KB articles or in the archives of the PEG.  As a customer I expect documentation to be correct and complete, every bit as much as I expect the code to be so.  If I read the docs and they say "you can do x" then I take it as read that I can do x.  If someone (Progress?) expects me to second-guess everything I read in the docs and verify it against other sources then (a) my productivity will plummet and (b) the docs are almost useless.

Also, the PEG, wonderful as it is, is not a Progress support channel.  It is unknown and invisible to many (most?) Progress customers, it is e-mail only and not searchable, and even if a given user subscribes to a channel where such discussions may happen they only see future conversations, not those in the past where, for instance, informal guidance may have been given about the "right" uses for CAN-DO.  There's a lot of good stuff on the PEG.  But as a medium for exchanging ideas and viewpoints, it also contains a lot of stuff that is just plain wrong (including some posts of my own).

Posted by Thomas Mercer-Hursh on 04-Mar-2014 13:06

Well, Rob, you have much higher expectations of the documentation than I do.  It is full of bad practice because the examples are there to show what the language features does, not how to use in in best practice.  And, while the @ clearly surprised a number of people, I have been seeing discussions about the misuse of CAN-DO for the majority of my 30 years experience in ABL.

Posted by Stefan Drissen on 04-Mar-2014 14:34

Works fine in 11.2.1 (on Vista x64), even reporting 'is' when silly enough to actually set DLC as an environment variable.

This thread is closed