Sheldon,
Choosing to authenticate using i5 user profiles obliges you to accept the protection i5 provides to prevent multiple sign-on attempts.
Just as anyone can disable any user profile if they are presented with a log in display on a green screen workstation, the same applies if presented with a log in display from an HTTP server.
I believe that is a good reason for using i5 profiles only when the HTTP server is accessible within a private network ( i.e. intranet vs internet).

My advice is that is better to use a validation list to store internet usernames. That's why they exist although you have to roll your own maintenance routine for maintaining the validation list. But that's not difficult as there are APIs for this.
A validation list does not prevent multiple attempts and usernames do not automatically expire and can be longer than 10 chars.

Peter

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Sheldon Foster
Sent: Thursday, 22 September 2011 6:46 a.m.
To: web400@xxxxxxxxxxxx
Subject: [WEB400] user credential authentication and persistence

I would sure appreciate some advice.



I've been programming in rpg for a few years and have some exposure to php, but am still in the learning process. I am trying to get a feel for what the best practices are for getting login information from a user and then maintaining that throughout the application.



These are the questions I have:

1) Is there a preferred method for validating a username/password
combination? I know of the following ways but am not sure of their pros/cons (other than in both cases a user could accidentally/purposefully disable another user's login):

a. Simply testing a connection using the user/pwd that was passed
using POST (filtering it first of course for any injections, etc.).

b. Using the rpg api QSYGETPH (get profile handle), check if a profile
handle is returned and if so then authentication is successful.

2) Is storing the username/password as session variables sufficient
(especially if they are encrypted)?

a. I know there is a php function called mcrypt. Would it be
sufficient to use this function alone to encrypt these variables?

b. Someone here on midrange.com suggested using the Zend framework to
extend the Zend_Session_Namespace in conjunction with mcrypt to accomplish this. My problem with this method is that we aren't really using the framework at this point (we may in the future), but I am wondering what this method has over a simple use of the mcrypt function alone.

3) Searching online, some have recommend storing the user credentials
in a database file instead of session variables. What are the pros/cons of this compared to using session variables?



Thanks for your time and expertise!



Sheldon



--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list To post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at http://archive.midrange.com/web400.

#####################################################################################

This correspondence is for the named person's use only. It may contain confidential
or legally privileged information, or both. No confidentiality or privilege is waived
or lost by any mistransmission. If you receive this correspondence in error, please
immediately delete it from your system and notify the sender. You must not disclose,
copy or rely on any part of this correspondence if you are not the intended recipient.
Any views expressed in this message are those of the individual sender, except where
the sender expressly, and with authority, states them to be the views of Veda.
If you need assistance, please contact Veda on either :-
Australia 1300-762-207 or New Zealand +64 9 367 6200

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.