Re: Net.Data and session management

No, just files. I really don't see the need to complicate things with a
user space.

Cookie on client's device that holds a random string (you could even Base64
encode it, which is what it looks like google and others may do).

That string relates in a table to the data I need (for example user id).

Brad
www.bvstools.com

On Fri, Oct 24, 2014 at 1:01 PM, Joe W Holt <joe.holt@xxxxxxxxxxx> wrote:

Brad, with that, are you maintaining static variables across sessions in a
file, or perhaps user spaces? I started with that direction as you
mentioned and have some minor apps that use user spaces to maintain those
variables across session requests. I can't think of another method that
would be good. The file idea came to my mind so that those variables would
be available to myself should I need to research them, but then again some
of those variables don't need to be accessed by anyone

***
Regards,
Joe W Holt
Sr Programmer/Developer
Jack Onofrio Dog Shows, LLC
405.427.8181



From: Bradley Stone <bvstone@xxxxxxxxx>
To: "Web Enabling the IBM i (AS/400 and iSeries)"
<web400@xxxxxxxxxxxx>
Date: 10/24/2014 12:53 PM
Subject: Re: [WEB400] Net.Data and session management
Sent by: "WEB400" <web400-bounces@xxxxxxxxxxxx>



We don't use Net.Data, mainly CGIDEV2 and eRPG SDK, but for session
management we use cookies. Easy, clean, simple and effective.

Cookies are there to be used. :) I think the days of people being
"afraid" of cookies is over, or at least it should be. With how easy they
are used with jQuery (or even on the server side)

Just be careful not to store any sensitive information in them.

Whenever we need to use a cookie, for example to show someone is "logged
on" we use a 256 byte random character string and have a x-reference table
on the i that we use to find out what that value "really" is.

For example, when a user signs on we generate a 256 byte string, write an
x-ref record (after making sure it's not a duplicate random string already
in use) with that 256 byte string and the real value (in this case, the
user's id) and store that 256 byte string in the cookie.

Then we have ILE subprocedures like getID() that retrieve the cookie value,
look it up in the xref, and return the real user id to our program on the
server.

Brad
www.bvstools.com

On Fri, Oct 24, 2014 at 10:44 AM, Joe W Holt <joe.holt@xxxxxxxxxxx> wrote:

I've noticed an uptick of Net.Data users posting so I wanted to push out

a

question. Back when I adopted Net.Data (when it first came out) I

developed

with it as mainly an interface to maintain session management using
persistence and calling rpg programs. Well with the passage of time
persistence is frowned upon even more so today. It is way too easy to
create an error forcing the persistence to bomb out and eject the user
data. I'm quickly writing the replacement application and am being

pushed

by relevance of technology to use other tools such as php. Not a big
proponent of using php on my box. I prefer CGIDEV2 and such tools that

are

relatively unknown outside of the 400 circles so that they aren't readily
high profile attack options. As I examine my apache logs I see countless
times the efforts being made in the public to take advantage of known
attacks these other platforms have fallen prey.

Anyone else adopt some session management styles with Net.Data that

would

be nice to implement? I've started using CGIDEV2 and userspaces with
cookies but it isn't a very clean approach due to my own haste and am
rethinking my options. I'm either going to have to adopt another tool

like

php, clean up the CGIDEV2 process, or use Net.Data with??? Any thoughts
would be great. I'm not with great confidence that Net.Data will survive
as an available product as technology continues to change. I was very
surprised (and relieved) to have it on 7.1.



***
Regards,
Joe W Holt
Sr Programmer/Developer
Jack Onofrio Dog Shows, LLC
405.427.8181
--
This is the Web Enabling the IBM i (AS/400 and 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 IBM i (AS/400 and 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 IBM i (AS/400 and 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.