0

I have a login module in my application of AS400(rpg400).Here user name and password are verified and only if password matches the user is given access to the Menu screen which further contains rpg programs to navigate to subsequent modules.

What i now want to achieve is when the user is verified, the logged in user name must appear in every screen or rather every rpg screen called.(ie user session must be maintained)Please refrain from guiding on admin properties.This is from a low level point of working.

Below is a PF on users:

       USER PF


A          R USRREC                
A            USER          10A     
A            PWD           10A     
A            USRTYP         2A     
A          K USRTYP

Keyed on user type.How can i allow the logged in person's variable accessible to all pgms?

techie
  • 467
  • 3
  • 8
  • 23
  • What happens when the QPWDLVL system value is set to allow longer passwords or pass-phrases (as it should be)? What happens when SSO is enabled and nobody has a password at all on the system? – user2338816 May 06 '14 at 10:59

3 Answers3

7

5250 displays aren't like HTML. There's no CSS that can be used as a standard template. You will need to specifically design every display to make it look the way you want it to. For this specific question, that means that you will put a user ID field on every display panel you want to see it on.

If I were designing this, I'd probably pass the user ID as a parameter to each RPG program, but there are many ways to pass information around.

  • Data area in QTEMP
  • Database file in QTEMP
  • LDA
  • User space in QTEMP
  • Environment variable (*JOB)

Passing the user ID as a parameter has the advantage that there is never a stale object that needs to be cleaned up. If a person has two user IDs - say she works in Accounting and Accounts Payable - and needs to sign off and back on to this internal security system, subsequent CALLs simply pass the proper parameter.

All of this could be avoided if the system could use the built-in IBM security. Then you could use the user profile that is part of the job name - see the Program Status Data Structure, positions 254-263 to get that within an RPG program. If you could use the IBM user profile, you wouldn't have to pass anything around; each program would be able to retrieve that information on its own; I'd put that into a service program so it's easy to reuse.

Buck Calabro
  • 7,558
  • 22
  • 25
  • +1 for the additional stuff, especially attempting to make it use the IBM login. Authentication is _hard_ , and IBM would have solved most of those problems for you. Of course, things are limited to 10 characters, which isn't exactly great, but... – Clockwork-Muse Aug 09 '12 at 20:22
  • @buck well i am working on rpg 400 so in dat case using pgm status data struc is difficult.If am to use the data area how should i proceed. – techie Aug 10 '12 at 06:38
  • Program status data structure is easily supported in RPG400. @JamesA posted reference links for using data areas, if you want to do that. – Buck Calabro Aug 10 '12 at 13:24
1

Sounds like an ideal use for the local data area or a regular data area created in QTEMP.

James Allman
  • 40,573
  • 11
  • 57
  • 70
  • The local data area is simple and well-understood by generations of RPG programmers. The down-side is that every app thinks that it and it alone uses the LDA. When some other app steps on 'your' LDA it leads to unwanted results. If you know that no other app on the system uses the LDA, then the LDA is a very good answer to the problem as stated. – Buck Calabro Aug 09 '12 at 21:26
  • You would be better off with an external data area in QTEMP. Or consider using environmental variables. LDA is not the best solution, if for no other reason than it can be stepped on by any program that doesn't know how you are using it. – WarrenT Aug 12 '12 at 05:37
1

If you are using the same user ID that they used to log onto the system, then you can use the USER keyword in your display files.

Do you really need to store user ID and password in a file that is inherently less secure than the way the operating system does it already? This opens a set of issues that you probably don't need to touch.

You can call a CL program or procedure which can use the CHKPWD command to enter their system password. Monitor for an error, and sign them off if there's a problem. Their password is secure (assuming you are using an SSL connection).

If you feel very strongly that you must have a separate password, consider storing a secure one way hash of the password. When they later enter their password, compute the hash on what they enter and compare it to the stored hash.

If you are asking users to enter a password after they are already logged on, then it seems safe to assume you are trying to address some security concern[s], so it seems reasonable to try to help you do so in a secure manner. This is a start.

WarrenT
  • 4,502
  • 19
  • 27
  • Incase i allow my system to have 2 typs of login functionality-one for existing users and other for new users to register n den login.In such cases how can i make sure which password keyword i need to specify in that `CHKPWD`. EG: `CHKPWD PASSWORD(JOHNJONES)` Here in place of johnjones how to dynamically assign var? – techie Aug 10 '12 at 06:43
  • How do these new users get on the system without signing on in the first place? – Buck Calabro Aug 10 '12 at 13:26
  • 1
    Generally, IBM i systems are set up so that one must request a user profile before being allowed to sign on, with IBM-supplied profiles being disabled, and no default general access allowed. Security philosophies generally try avoid giving an inch, lest someone somehow find an unanticipated way to exploit that into a yard. [Change that to cm & m, if you prefer ;) ] And build redundant layers of security, in case other layers fail. But passwords deserve the utmost care, even on a trivial system, since users sometimes use them in multiple cases, so a compromise here may unlock other doors. – WarrenT Aug 10 '12 at 13:30