Re: 'green screen' not sellable --> WE(?) are the problem

Gents

try to use Gmail with Crome.

Crome shows you a list of resent used homepages when you opens a new tab.

Go to another computer, start Crome and log into your google account - hey
the same resent used homepages appears when you opens a new tab.

Is that hidden in a cookie - if so cookies can mysteric be tranferred
between
computers - or maybe it is saved by google on their servers - what do you
think?

On Thu, Jun 11, 2015 at 11:20 PM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

Brad

in fact nothing happens - beside they don't can recall our user id and
password
next time you log in.

Nice to have user id's and passwords floating around in cookies - don't
you
think ?

On Thu, Jun 11, 2015 at 10:23 PM, Bradley Stone <bvstone@xxxxxxxxx>
wrote:

Sign into all your google and/or microsoft accounts, clear your cookies,
and then see what happens. You may want to let google and MS know
session
cookies are "old and unsafe". :)

Brad
www.bvstools.com

On Thu, Jun 11, 2015 at 2:55 PM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

Bradley



In practice AJAX calls are never made while other things are loading

and

therefore number of connections are arbitrary and only controlled by

the

browsers maximum.



In regards to cookies for session management it is a rather old and

unsafe

technology to use. You may hold a session number in a cookie but that
aren’t really not enough. You will need server side managed security.

On Thu, Jun 11, 2015 at 8:07 PM, Matt Olson <Matt.Olson@xxxxxxxx>

wrote:

This is not a windows limitation. It is a browser implementation

detail.

http://www.browserscope.org/?category=network


-----Original Message-----
From: Bradley Stone [mailto:bvstone@xxxxxxxxx]
Sent: Thursday, June 11, 2015 1:01 PM
To: Midrange Systems Technical Discussion
Subject: Re: 'green screen' not sellable --> WE(?) are the problem

Another problem is most Windows PC limit to 4 (or is it 2?)

connections

at

once... so if a page is loading images, running ajax, retrieving JS

or

anything else from a server it may not load as fluidly as possible.

Not

sure how *nix distros or iOS handle this.

As far as using session cookies, I've used them for years with great
success. Just create 256 byte (or larger) random (but unique) keys

and

use

that (as well as local IP address you can get from environment

variables,

or any other info) to tie it back to the info on the server side (ie,
customer number, sign on info, etc). Base64 encode it too if you

want.

:)

Yes, someone could manipulate the cookie, but I doubt they'd figure

out

the proper 256 byte sequence to get logged onto someone else's PC as

well

as spoofing the local IP of the user.

Brad
www.bvstools.com


On Thu, Jun 11, 2015 at 10:40 AM, Henrik Rützou <hr@xxxxxxxxxxxx>

wrote:

Nathan

<iframes> is not the problem, AJAX is since many modern UI's

initiates

parallel AJAX conversations.

To illustrate that here is what happens when I fire up my Viewport.

The Viewport has an accordian menu where each main topic is an

object

that is populated by the server through an AJAX call.

This means that if there are 5 main topics the client will fire

five

AJAX call's to the server for the menu content under its topic.

What happens behind the scene is illustrated here:

http://www.powerext.com/RESTTIER0.png



On Thu, Jun 11, 2015 at 5:07 PM, Nathan Andelin <

nandelin@xxxxxxxxx>

wrote:

Henrik,

Thanks for the reply. If I understand correctly, there are at

least

two problems with "persistent CGI". First, when the "maximum"
threshold is reached, then existing "sessions" may be closed to

accommodate new users.

The second problem is that developers may be forced to create

some

rather unique plumbing in order to accommodate certain

application

designs, such as using <iframes>, where each frame may need to

implement AJAX.

On Thu, Jun 11, 2015 at 8:07 AM, Henrik Rützou <hr@xxxxxxxxxxxx>

wrote:

Nathan



It is a combination of several things.



Normally the Apache server runs it QZSRCGI jobs under a common

userprofile

(serverUserId) in the config file. That is that the QZSRCGI job

actually

runs under user QTMHHTTP as job user id and the common user

from

the

server

config as adopted/actual user profile.



The number of possible QZSRCGI jobs under and Apache instant is
also a config setting.



If all QZSRCGI jobs are active processing and a request comes

in

the request I queued until a QZSRCGI job is idle.



When you set up the Apache to run persistent this scenario is

changed.

QZSRCGI jobs now runs under the real user profile as
adopted/actual. A

new

request will cause apache to create a new QZSRCGI job for the

requesting

user.



When the allowed number of active QZSRCGI jobs is reached and a
new

user

makes a request the trouble starts. What Apache will do is to

find

the first idle QZSRCGI job allocated to another user, close it
down and

start a

new QZSRCGI job for the new user. This will of course mean that
the

closed

job will lose persistency.



Now, today we run AJAX and AJAX may fire parallel requests from
one

client

against the Apache server. The Apache server will not queue

this

request

for one QZSRCGI job but execute them in different QZSRCGI jobs

and

that doesn’t matter if you run stateless or persistent.



So suddenly one user may have a number of in this case

persistent

QZSRCGI

jobs and nobody knows which of the jobs are used for a single

request.

This

will of course also add to the overhead of closing and

restarting

QZSRCGI

jobs when the maximum threshold is reached.



There may be techniques to avoid this behavior, but as

standard I

will

not

call it persistent.

On Thu, Jun 11, 2015 at 3:36 PM, Nathan Andelin
<nandelin@xxxxxxxxx>
wrote:

PS. If you run Apache there is no such thing as persistent

CGI

but

that

is

another rather long story. If you like I could explain it.

Henrik,

Yes, I would be interested in your views about "persistent

CGI"

under Apache. My understanding is that Profound UI uses it.

And

it seems to maintain a session which may time-out after a

period

of inactivity.

What

makes you say there is "no such thing"?

BTW, I agree with your method of storing "session" variables

in

an

IBM

i

DB, keyed by a secure value.
--
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.

--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>
--
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.

--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>
--
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.

--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>
--
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.

--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>

--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>