× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I think the use of form authentication is much more appropriate for web applications, for the reasons Aaron mentioned.

As far as letting a connection run as "NOBODY," it seems counterintuitive that you could gain performance by creating a second "NOBODY" connection when you've already created a connection on behalf of the user. You should be able to have equivalent or better performance with the named user connection. In addition, you gain transparent enforcement of DB2's security and auditing at the database level.

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Kelly Cookson
Sent: Sunday, November 08, 2009 2:46 PM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] PHP - authenticate and authorize using AS400 profile

Honestly, I'm not familiar with most of what you mentioned. I'm still
pretty green when it comes to PHP on the AS400.

Can Zend Core for i5 be similarly configured to use the AS400 system
password file?
I'm not running Apache per se. I'm running Zend Core for i5, which
installs an instance of the IBM HTTP server for i5/OS. I searched the
Zend Core for i5 User Guide and the Zend for i5/OS redbook and didn't
see how to setup the configuration you describe.

How does the arrangement you describe handle user authorization?
I'm not just interested in authentication. I also want to make sure
users have the authority to access a particular PHP script. For example,
I don't want any user with a valid AS400 name and password to run a PHP
script that updates payroll files. I want to make sure the user belongs
to the PAYROLL group. Only users in the PAYROLL group are authorized to
update the payroll system files.

Does UserID %%CLIENT%% mean my PHP scripts will connect to DB2 files
with the user's name and password?
If so, I don't want that. I will get better performance from my PHP
scripts if I connect to DB2 files with the NOBODY profile. The only
reason I want to connect to the AS400 with the user's name and password
is to authenticate the user and check the user's authorities. I want to
close that connection and use the NOBODY profile after that.

Thanks,
Kelly


-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Peter Connell
Sent: Sunday, November 08, 2009 1:11 PM
To: 'Web Enabling the AS400 / iSeries'
Subject: Re: [WEB400] PHP - authenticate and authorize using AS400
profile

Perhaps I am missing the point of this but if the task is to provide a
web page the can only be used by an AS400 profile then this is commonly
achieved by setting the Apache configuration to require that such pages
are protected by the AS400 system password file ( PasswdFile %%SYSTEM)
and assigning Basic Authentication (AuthType Basic). By also setting
these requests to run as UserID %%CLIENT%% then the HTTP server takes
care of security automatically and any server-side functions performed
by the web page will already have been authenticated by the HTTP server
and can be trusted to execute under profile designated by the server in
the REMOTE_USER environment variable which can be passed to any user
defined routine.

Peter

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Kelly Cookson
Sent: Monday, 9 November 2009 12:33 a.m.
To: Web Enabling the AS400 / iSeries
Subject: [WEB400] PHP - authenticate and authorize using AS400 profile

I've been working on a PHP function that: (1) authenticates a user by
connecting to the AS400, and (2) authorizes a user based on information
from the user profile. I've included the code at the end of this post.



The code works. My question has to do with accepting the user name and
password from the $_POST array.



I know the mantra is "never trust user input." However, we use long
passwords, and we encourage users to make up passwords that include
special characters. Do I need to scrub the input at all, since I'm only
using it to establish a connection and set a $_SESSION variable? Should
I scrub certain characters (and tell users they can't include those
characters in their passwords)? If so, which characters?



Thanks,

Kelly



Note: the script below assumes users are authorized to access an
application if they belong to the *SECOFR user class or they belong a
supplemental group called MYGROUP.



function validateUser()

{

//Step 1: Authenticate the user by connecting to the AS400.

$username=$_POST["user"];

$password=$_POST["password"];

$conn = i5_connect("myas400",$username,$password);

if (!$conn)

{

$result = "Invalid username or password.";

}

else

{

//Step 2. Authorize the user by checking profile information;

$rtvusrprf = (i5_command("rtvusrprf",

array("usrprf"=>"*CURRENT"),

array("usrcls"=>"usrcls","supgrpprf"=>"supgrpprf"),

$conn));

if (!$rtvusrprf)

{

$result = "Authorization error.";

}

else

{

if ($usrcls == "*SECOFR")

{

$_SESSION["user"] = $username;

$result = "Thank you for signing in.";

}

else

{

$supgrps = str_split($supgrpprf, 10);

if (in_array("MYGROUP", $supgrps))

{

$_SESSION["user"] = $username;

$result = "Thank you for signing in.";

}

else

{

$result = "Not authorized for this application.";

}

}

}

//Step 3. Close connection. Use the NOBODY profile for better
performance.

i5_close($conn);

}

return $result;

}






As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.