× 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.



Program - when we create the session id and write to the database we set a timeout field in the db. On each hit we update the timeout date/time. If the next hit is over the timeout we redirect the user to the logon page

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Gibbons, Michael
Sent: Monday, August 27, 2007 8:47 AM
To: 'Web Enabling the AS400 / iSeries'
Subject: Re: [WEB400] Web site authentication

Thanks Mike,

Sounds simple enough. Could you tell me how you timeout or invalidate the
cookie/database record? Is it a program setting or a server setting.
Thanks
Mike

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Mike Cunningham
Sent: Monday, August 27, 2007 8:41 AM
To: 'Web Enabling the AS400 / iSeries'
Subject: Re: [WEB400] Web site authentication

Start here
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/sec1.pdf
and in particular the Get Profile Handle (QsyGetProfileHandle) API

Basic operation would be for you to put up an https page asking for userid
and password. Then have whatever app you use for the page (we are using RPG
CGI but it could be java/jsp/php - anything that can call iSeries
applications) and send the userid and password to the API. The API will
return errors that you need to deal with or it will not and the
userid/password is valid. At that point our CGI app generates the random
hashed 64 byte session id and we write a database record with the session id
and userid and also send a cookie to the browser with the 64 byte session
id and send back a web page of links that user id authorized to. Every web
app we write asks the browser for our cookie, checks the database to see if
that cookie is valid and if so allows the app to run. All of that work is
done in one program and all web apps just call it.

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Gibbons, Michael
Sent: Monday, August 27, 2007 8:24 AM
To: 'Web Enabling the AS400 / iSeries'
Subject: Re: [WEB400] Web site authentication

Mike,

Could you give us a little background on how you got started with the IBM
API's? This topic is coming up quick on my list.

Thanks

-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Mike Cunningham
Sent: Monday, August 27, 2007 8:18 AM
To: Web Enabling the AS400 / iSeries
Subject: [WEB400] Web site authentication

I am interested in a quick poll on how other iSeries shops who are
developing web applications are doing authentication. Are you using the
built in Apache mod? If so are you authenticating using iSeries userids,
LDAP or Auth Lists? If not using the Apache mod did you write your own with
the same questions on what directory you authenticate against. Are you
using persistent sessions or browser session cookies to maintain who is
doing what?

To answer for myself, we wrote our own authentication process using the IBM
APIs to validate userid/password against iSeries userids but are going to
extend that to also authenticate over LDAP to our Active Directory tree. We
are not using persistent sessions and use session cookies. The cookie has
nothing but a 64 byte string that we create on logon and keep in the
database. Every hit is checked to see if the cookie exists, has not timed
out and who it is associated with.
--
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 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 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 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.



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.