RE: Authorizing program access

[David FOXWELL <David.FOXWELL@xxxxxxxxx>]

I prefer the idea of putting the control in the target program itself to avoid cheating. I have seen a control program that checks the user's right to access a menu option by coding the user, menu and option in a PF. To get round it you just call directly, and if the menu option gets changed....

So I'd like to have such a mayIrun procedure. Then I can have one procedure and different rules for different programs.
But back to my original question, how do I get the message sent by mayIrun to the message line in the menu ?

CLP2 gets the message from canIrun, then does SNDPGMMSG to CLP1 called from the menu. What's the correct syntax for this ?

Thanks


-----Message d'origine-----
De : midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] De la part de Alan Shore
Envoyé : lundi 15 septembre 2008 17:56
À : Midrange Systems Technical Discussion
Objet : Re: Authorizing program access


I like Authorization lists, and I have used them a lot, but the unfortunate thing with authorization lists is that if a user has *ALLOBJ, it makes no difference whether that user is or is not on the authorization list. Unless things have changed in the last 4 years since I last used one.



Alan Shore
Programmer/Analyst, Direct Response
E:AShore@xxxxxxxxxxx
P:(631) 244-2000 ext. 5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill

midrange-l-bounces@xxxxxxxxxxxx wrote on 09/15/2008 11:37:58 AM:

> Well, one way of coding security is to not put it in a PF, but to put
> it in an authorization list (WRKAUTL).  Then secure the program with
> that authorization list.
> Granted, if you are already using an authorization list on all your
> programs and a different one for this program it can cause maintenance
> headaches.  For instance it rather shoots CHGAUT
> OBJ('/qsys.lib/mylib.lib/*.pgm') AUTL(MYAUTL)
>
> That, and the message thrown by PGMA when it calls PGMB which is
> secured by the special authorization list may not be as friendly
> unless you wrapped the CALL with an RPGLE Monitor code or a CL MONMSG code.
>
> Keep in mind, that if you do use the file method that you have to
restrict
> how the user may otherwise call the program.  For instance, if they
> have command access and can manually type in CALL, or any of the other
numerous
> methods of executing a program.  One way of handing that is to have
> the final called program do the security check itself.
>
> And putting the check into a service program may be a desirable
> alternative.  That way if you change the method from a file to
> whatever none of the secured programs will have to change.  They
> continue to execute MayIRun(pgmname) and MayIRun returns an aye or nay.
>
> Rob Berendt
> --
> Group Dekko Services, LLC
> Dept 01.073
> Dock 108
> 6928N 400E
> Kendallville, IN 46755
> http://www.dekko.com
>
>
>
>
>
> David FOXWELL <David.FOXWELL@xxxxxxxxx> Sent by:
> midrange-l-bounces@xxxxxxxxxxxx
> 09/15/2008 11:15 AM
> Please respond to
> Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
>
>
> To
> Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> cc
>
> Subject
> Authorizing program access
>
>
>
>
>
>
> Hi folks,
>
> I have a request to restrict the use of a client update program
> depending

> on a user's authority level which is already coded in a PF.
> The program is an RPG called from a CL which is called from a menu.
>
> I would like to be able to test the user's right to access the program
> in

> the RPG or CL and the use SNDPGMMSG to display the message at the
> bottom of the menu.
>
> I'm having trouble getting to grips with SNDPGMMSG. If I have : Menu,
> CLP1, CLP2 and I detect the message in CLP2, how do I get it the
> message to display on the menu?
>
> I also have a sneaky feeling that this isn't the right way to go about
the
> problem. Shouldn't there be a repertoire of programs with such a level
> of

> security and the level of security needed to access them?
>
> Thanks.
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
> unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
> a moment to review the archives at
> http://archive.midrange.com/midrange-l.
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
> unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take
> a moment to review the archives at
> http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.