>My first thought was to generate a session id that would then be written toa file along with the additional info that I want to keep and then haveaprocedure that would retrieve the info based on the session id as thekey.
That's the way to do it. I can't speak for pages coming from RPG -- as I don't do it that way -- but basically you define your own meaning of the term "session." As it's generally implemented, a session is defined by a cookie that's set on the client. Since the browser passes back the cookies for a site w/each request the cookie becomes your key into the session database.
If your "applications" are held on different machines (or on different sites on the same machine) you'll need to extend the process used to pass the session key since cookies aren't passed between sites. But when you're changing sites you could always pass the "cookie" as a form field, or as part of the URL.
I've shared "sessions" between ColdFusion (JSP), ASP and ASP.NET applications hosted on several machines, works great. And thinking about it now, there's no reason I couldn't add an RPG web-app into the mix, it would continue to work.
From a DB point of view, my session system is rather simple. It's twotables, the first is the session header, the second the session entries.
Session table looks something like: SessionID int SessionKey Guid SessionIP int SessionCreate datetime SessionLastAccess datetime
Session Entry table: SessionID int (FK to Session) SessionEntryKey varchar(50) SessionEntryValue varchar(200)
The obvious limitation is that I can't store anything in session that's greater than 200 bytes -- and that's ok in my case. If I needed to I could always store a BLOB and then serialize anything into session.
As for usage, I've encapsulated all session access into get() and set() functions. A call to either requires the SessionKey and SessionEntryKey. Get() returns the SessionEntryValue for that key in that session, Set() takes SessionEntryValue as a parm and sets the value in the database. A call to either updates SessionLastAccess to be now.
There's a background task that looks at all sessions and kills any w/a lastaccess more than xxx minutes old (we're set to 60).
Oh, and SessionID (the int) is only used internally. The value that's passed back and forth is the sessionkey and looks like: F6724590-3EB6-4442-95D5-1471D04D6EB9 for example.
------------ Walden H Leverich III President & CEO Tech Software (516) 627-3800 x11 WaldenL@xxxxxxxxxxxxxxx http://www.TechSoftInc.com
Quiquid latine dictum sit altum viditur. (Whatever is said in Latin seems profound.)
-----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Swaim Sent: Friday, 18 February, 2005 10:06 To: MIDRANGE-L@xxxxxxxxxxxx Subject: How to keep persistant data between web apps
I am just now starting to program for the web. I am running V5R1 (with all current ptf's) I am working through the easy400 deliverables and modifying them to meet my needs. I am trying to create a web application framework that would allow our Distributors to log into the website and then have access to there account information.
The problem that I am facing now is try to keep data persistent between applications. I know that I can create a session HANDLE that will allow for persistent for one app. I would like for the user to log in using my own auth method and then keep the information (i.e. customer number, agent code, etc) to be used for other apps on the site.
My first thought was to generate a session id that would then be written to a file along with the additional info that I want to keep and then have a procedure that would retrieve the info based on the session id as the key.
I am new to this area for web programming. I would like to stay with RPG as my language as that is what I am most familiar. I am familiar with PHP but I do not have the PASE environment installed on my machine to run PHP with my Apache server.
Thank for any input.
-- 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,
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact