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



Scott,

Since I need to hit the header to translate the GUID to the int for the
SessionID I decided to store the LastAccess on the header. However, if
you use the GUID as a the key to the sessionentry file you could simply
sore a lastaccess on each entry. 

The cleanup routine would then check all the lastaccess timestamps for a
session and delete the session if none of them had been touched
recently. It's more IO in the cleanup routine, but less in the get/set
routines.

-Walden

------------
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 12:00
To: Midrange Systems Technical Discussion
Subject: Re: How to keep persistant data between web apps

I think that I Will go this route.  have the initial log in program
generate 
a random session id.  Have this written to a file along with he
additional 
information that I would like to keep.  then just pass the session id to

every app from that point on.  Then each app would have a function that 
would use the sessionid to retrieve the additional info and use it for
that 
customer.  Updating a expiration date with every use so that after a 
specified period of time a server program would go through the file and 
remove all of the expired sessions.

Thanks for the insight.  I was leery of using the cookie/hidden field
method 
for the same reasons that Weldon gave.  Although I would not be keeping
any 
sensitive data such as Credit Cards, the data would be sensitive to my 
company.

Thanks again.

Scott Swaim
----- Original Message ----- 
From: "Walden H. Leverich" <WaldenL@xxxxxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent: Friday, February 18, 2005 10:09 AM
Subject: RE: How to keep persistant data between web apps


> >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.
>
> 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 two
> tables, 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.
>
> Make sense?
>
> -Walden
>
>
> ------------
> 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.
>
>
> Scott Swaim
>
> -- 
> 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,
> 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,
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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.