Session Control in PH Web - new feature suggestion for phweb

Wed Aug 8 08:20:01 CDT 2007

Forgot to mention that the dictionary open name for the file was
$v_dict_session_file, so the variable had to be set before the file could be
opened.

  _____  

From: powerh-l-bounces+atla38=dsl.pipex.com at lists.sowder.com
[mailto:powerh-l-bounces+atla38=dsl.pipex.com at lists.sowder.com] On Behalf Of
Joe Boyle
Sent: 08 August 2007 13:45
To: 'Han Han'; powerh-l at lists.sowder.com
Subject: Re: Session Control in PH Web - new feature suggestion for phweb

the file v_dict_session_file.in contained the two lines below,

create file dict_session_file
exit

----- Original Message ----- 

From: Joe Boyle <mailto:atla38 at dsl.pipex.com>  

To: 'Han Han' <mailto:kim_han79 at yahoo.com.sg>  ; powerh-l at lists.sowder.com 

Sent: Wednesday, August 08, 2007 1:03 PM

Subject: RE: Session Control in PH Web - new feature suggestion for phweb

I am guessing that if two users login at the same 8 digit time ( I don't
know if the processing of PHweb would ever enable this) , the PHrandom
function will return the same value; so, I would say that a reasonably
unique browser IP ( in conjunction with 8 digit time) would be more
effective than a PHrandom result.

That said, the windows %random% call seems pretty useful, but a database of
used session id's (%random%  values) would probably need to be maintained -
however they are generated, in order to ensure that you aren't giving out
duplicates.

If the PHwebservers were able to maintain a counter in memory, incremented
when activated, and the individual PHwebservers per application worked on
specific ranges of values, a unique sessionid would easily be available. 

In conjunction with date and 8 digit time the combined result would be
unique, even if the PHwebserver were left running for thousands of years (
an 8 byte integer using only fifty two bits can count up to 4503599627370496
- I only ever saw quiz accurate up to about 8999999999999999 - 52ish bits ).

I have some notes containing some tips on returning random values below, it
wasn't complete, but the approach worked at the time for PH on Windows (
didn't test with PHweb). With MSSQL I still like the idea of referencing an
autoincrement column, but the key segments have to be unique in order to
retrieve the correct row - so that obviates the need for the autoincrement
column.

type dict_session_file.cmd

set v_dict_session_file=%1

echo %v_dict_session_file%

qutil < c:\ph\sqlserver\v_dict_session_file.in >
c:\ph\sqlserver\makefile.log

exit

type idsession.qts

can cle

run n1

req q1 proc lim 1 input lim 1

acc file_lock

choose orderid 99999999

define t_sess char*10 = parm

output dict_session_file add

item word final t_sess

type idsession.qks 

can clear

screen idsession  menu 

temporary t_seed integer *8 size 4 reset at startup 

temporary t_sess float reset at startup 

temporary t_count integer reset at startup 

temporary idfile_temp character *100 reset at startup 

temporary rc_temp character *150 reset at startup 

file dict_session_file designer close 

field t_sess id 1     

procedure internal isef

begin

let idfile_temp = truncate ( &

 "c:\ph\sqlserver\f_" + ascii( sysdate ) + ascii (systime) + ".dat")

if not setsystemval ("v_dict_session_file", idfile_temp )

then error "not set " 

let rc_temp = "cmd /c c:\ph\sqlserver\dict_session_file.cmd " +  idfile_temp
+ " > c:\ph\sqlserver\dict_session_file.log"

run command rc_temp

let rc_temp = "cmd /c echo %random% > c:\ph\sqlserver\idsession.ran "

run command rc_temp

let rc_temp = &

;both below work fine

;"cmd /c qtp auto=c:\ph\sqlserver\idsession.qtc <
c:\ph\sqlserver\idsession.ran > idsession.log"

"cmd /c echo %random% | qtp auto=c:\ph\sqlserver\idsession.qtc >
idsession.log"

run command rc_temp 

get dict_session_file       seq

close dict_session_file

info  = word now response

end

procedure internal ises

begin

let t_sess = random( t_seed)  * 1000

end

procedure initialize

begin

let t_seed = systime

let t_count = t_count  + 1

do  internal isef

display t_sess

info = ascii (t_count) + " <> " + ascii ( t_sess) now            response

return

end

build list

  _____  

From: powerh-l-bounces+atla38=dsl.pipex.com at lists.sowder.com
[mailto:powerh-l-bounces+atla38=dsl.pipex.com at lists.sowder.com] On Behalf Of
Deskin, Bob
Sent: 07 August 2007 18:00
To: Joe Boyle; Han Han; powerh-l at lists.sowder.com
Subject: RE: Session Control in PH Web - new feature suggestion for phweb

Reasonably unique is not unique. Browser IPs as provided by the Web server
environment variables provide the IP to return the results page to the
browser. But if the browser is behind a router, that IP may not be unique to
a specific PC. Regardless, we do have an enhancement on the list to provide
these values.

As for a system function, it's probably not worth the effort since any value
that's received in the request can be obtained by declaring a temporary and
doing an ACCEPT in the INITIALIZE procedure. 

As for generating a unique ID, there are many different requirements and
it's easier for customers to put their own together from things like
SYSDATETIME, the result of the RANDOM function, and so on.

Bob

-----Original Message-----
From: Joe Boyle [mailto:atla38 at dsl.pipex.com] 
Sent: August 7, 2007 12:53 PM
To: Deskin, Bob; 'Han Han'; powerh-l at lists.sowder.com
Subject: RE: Session Control in PH Web - new feature suggestion for phweb

Given that the return address of the browser must be reasonably unique,
allow a system call ( along the lines of 'userid/logonid') to return the
value of the address of the browser.  This would help enable sessionid
processing.

Obviously, it would be even easier if PHweb simply generated the equivalent
of a unique sessionid :-)

  _____  

From: powerh-l-bounces+atla38=dsl.pipex.com at lists.sowder.com
[mailto:powerh-l-bounces+atla38=dsl.pipex.com at lists.sowder.com] On Behalf Of
Deskin, Bob

<SNIP> :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sowder.com/pipermail/powerh-l/attachments/20070808/c6639482/attachment.htm