Re: Witango-Talk: variables getting muxed

[Robert Garcia]

Making sure the userref was not in the URL, was POST v5 fix, I don't  
think this will help, and maybe make worse. I don't remember all the  
discussions we had, but I am pretty sure, it was determined by all of  
our testing, with v5 plus, especially v5.5, remove from URL, but I  
don't think with 2000.

--
Robert Garcia
President - BigHead Technology
VP Application Development - eventpix.com
13653 West Park Dr
Magalia, Ca 95954
ph: 530.645.4040 x222 fax: 530.645.4040
[EMAIL PROTECTED] - [EMAIL PROTECTED]
http://bighead.net/ - http://eventpix.com/

On Sep 26, 2007, at 9:49 AM, Roland Dumas wrote:

There were ancient discussion threads on this subject, of defeating  
caches and preventing session hijacking.

In addition to the no-cache headers, making sure the userref isn't  
in the URL, and such, you can also add a random variable to the URL  
to help defeat the proxy caches.  Just add a variable to the URL as  
in ?rand=  and create a random number generator to complete the  
variable.

You put it on any link so that the proxy server will see it as a  
unique page.

There are also many ways in which a session can end up getting  
shared. One is by forwarded links. I see a page I love and email  
the URL to a buddy who clicks on it before my session has expired.  
We're now sharing a session. It gets put on a mass email, and  
people can keep joining it in perpetuity even after you're stripped  
the userref from the URL.  You're particularly vulnerable when the  
IT department has a policy of not allowing cookies.


On Sep 26, 2007, at 9:37 AM, Jesse Parker wrote:

I have experienced a lifetime supply of issues like this with several
different technologies.

In basically all cases the root cause turns out to be aggresive  
cacheing by
the proxy.

Try adding lines like this in the HTTP header:

Pragma: no-cache
Expires: Fri, 30 Oct 1998 12:00:00 GMT (date not important, but  
should be
the distant past)

In my experience the standard sessioning mechanisms (cookie,  
argument) work
fine once the proxy understands not to cache.  NOTE that using META
HTTP-EQUIV tags are not likely to be respected by the proxy server  
- it has
to go into the header.


-----Original Message-----
From: WebDude [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 26, 2007 12:12 PM
To: witango-talk@witango.com
Subject: RE: Witango-Talk: variables getting muxed


Okay...

A few more details. I am using Witango2000. Not sure if this is a  
problem.
Also, the problem is just with this one client. I removed all the
<@USERREFERENCEARGUMENT> tags in all urls. All users are surfing  
through a
firewall and are showing up with the same IP address. The hijacks  
appear to
be random. I have asked the client to have all users remove their  
bookmarks
and we will see if this helps. This will eliminate any  
<@USERREFERENCE>s
that have been accidently bookmarked.

What is frustrating is that I cannot reproduce any problems here,
internally. I also have a firewall and all surfing is done through  
a single
IP. I have logged in as many various users using different  
browsers, browser
sessions, PCs, Macs, etc. Everything here seems to be working as  
expected.
The only time I get a hijack is when I create a new window from  
the same PC,
log in as a different user and go to the original window and hit  
refresh.
What they are explaining to me is that one user will log in on one  
machine,
another will log in on another and see the variables that were set  
on the
first login...huh?!?!?!?! I don't get it. It has to be something  
on their
end, as far as I can tell. This is the only reason I was going to  
explore
the cookie option.

Could it be a proxy thing? A caching thing? I was told they just  
set up a
new firewall last week. Unfortunately, I am not sure if this is  
the issue or
not. I just started development of this project 2 weeks ago. It is  
still in
the testing phase.

In the past, the only time I have used cookies was to give members  
of some
of our forums a way to not have to log in every visit. I have  
never had any
problems with this.

I am waiting for a call from their IT guy to see how they have their
firewall set up, but to tell you the truth, I cannot see anything  
on a
firewall that would do something like this.

That's where we are at at this point.


-----Original Message-----
From: William M Conlon [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 26, 2007 9:54 AM
To: witango-talk@witango.com
Subject: Re: Witango-Talk: variables getting muxed

Witango 5+ handles the setup of the session cookie containing
<@USERREFERENCE> for you, and this is preferred over using
<@USERREFERENCEARGUMENT> in the URL.  See the old discussion  
threads for an
explanation, but one of the reasons is to avoid 'session  
hijacking'.  So if
you eliminate <@USERREFERENCEARGUMENT>, your user scope variables  
will still
be associated with the <@USERREFERENCE>.

There is no need to pass your user scope variables (login, fname,
etc.) as cookies.  In fact that just exposes them to snoopers.

Bill

William M. Conlon, P.E., Ph.D.
To the Point
2330 Bryant Street
Palo Alto, CA 94301
    vox:  650.327.2175 (direct)
    fax:  650.329.8335
mobile:  650.906.9929
e-mail:  mailto:[EMAIL PROTECTED]
    web:  http://www.tothept.com


On Sep 26, 2007, at 7:21 AM, WebDude wrote:

Okay... I need a cookie education then, I guess.

I use cookies on some of my forums strictly to remember just a
username.

On this site, however, there are a bit more variables to be
remembered.
login
lname
fname
password
logged
department
security
officebranch
etc.
etc.

So, if you kind folks could give me a clue...

Do I set all of these as cookies?
I would like the cookies to expire at the end of each session, I see
how to do that in the variable set function... what exactly is the
code for setting cookies? I am all over the help pages and cannot  
find
this.

Each page (a hundred or so right now) is set to look for <@VAR
logged> and if it is set to 1, it goes to the next elseif. Can I
set <@VAR logged> in the cookie scope and then simply check it?  
Or do
I have to define the scope too. In otherwords, if I assign it using
the cookie scope, will the following still work?

<@IFEQUAL <@VAR logged> "1">do this<@ELSE>do that</@IF>


Sorry for the stupid questions...



John Muldoon
Corporate Incentives
3416 Nicollet Ave S
Minneapolis, MN 55408-4552
612.822.2222
[EMAIL PROTECTED]
<ci.gif>
http://cipromo.com



From: William Conlon [mailto:[EMAIL PROTECTED]
Sent: Monday, September 24, 2007 1:47 PM
To: witango-talk@witango.com
Subject: Re: Witango-Talk: variables getting muxed

Sounds similar to session hijacking (we had a discussion on this In
January 2006). Use cookies instead of passing the userreference  
in the
URL.

--bill
On Sep 24, 2007, at 8:02 AM, WebDude wrote:

Mmmmmm...
That sounds like a good idea. Check to see if Vars are set and  
if so,
ask them to logout.
John Muldoon
Corporate Incentives
3416 Nicollet Ave S
Minneapolis, MN 55408-4552
612.822.2222
[EMAIL PROTECTED]
<ci.gif>
http://cipromo.com

From: Robert Garcia [mailto:[EMAIL PROTECTED]
Sent: Monday, September 24, 2007 9:52 AM
To: witango-talk@witango.com
Subject: Re: Witango-Talk: variables getting muxed

First, I would remove all references to <@userreferenceargument> in
urls completely if you are using witango v5.5.

Second, we had an issue like this, and it stumped us for a long  
time,
until we watched what the users were doing. Users think, that if  
they
open another browser window, or tab, it is a SEPARATE space.  
They may
open a second window or tab, and login as another employee, for
whatever reason, to check something real quick, or whatever, then
close that window, and expect the previously opened window to  
work as
it did, with the former employee. However, the new login, from the
new window overwrote the user vars, for this session, which  
includes
BOTH WINDOWS OR TABS.

The only way to eliminate this, is to check on login, if any or one
of the user vars are set, if so, you must tell them they have an  
open
session that must logout from first. This type of problem usually
only happens on employee type internal sites, I don't usually worry
about it with consumer sites.

--

Robert Garcia
President - BigHead Technology
VP Application Development - eventpix.com
13653 West Park Dr
Magalia, Ca 95954
ph: 530.645.4040 x222 fax: 530.645.4040 [EMAIL PROTECTED] -
[EMAIL PROTECTED] http://bighead.net/ - http://eventpix.com/

On Sep 24, 2007, at 7:12 AM, WebDude wrote:

Hi all,
I have a strange thing happening with one of my clients. We are
still in the process on trying to find the problem. It might be a
firewall issue on thier end, but I thought I might ask a couple of
questions here.
I have a site for a company that has around 150 employees. It  
is an
employee site. Each employee has a login and password. When they
login, some variables are set to keep track of the user and for  
them
to edit their personal profile. etc. As of Friday, the users  
started
getting muxed. In other words, users would login as one employee,
but it shows them as another. This happened several times and I am
trying to get to the bottom of it. All users come in on a range of
IPs, 5 of them, I believe. I tested , retested, and tested again,
but cannot reproduce the problem on my end. I used several  
machines
ALL on the same IP address and logged in as different users on all
of these machines to see if I could break it... and I cannot.
I did notice that some of the URLs I have in some menus did not  
have
the <@usereferenceargument> while some did. I changed all links in
the project to include the <@usereferenceargument> hoping this  
would
help in carrying the correct variables while surfing.
Also, since this is a new project and we are still in the testing
phase, some of the changes I am making are not being seen by  
some of
the users on their end. I have had them clear cache, re-log in,  
even
reboot thier machines and still these users do not see the  
changes.
I assume that they may have a caching server on thier end that may
be a problem.
The site was running perfectly okay on thier end until Friday, and
then something changed. So their secondary IT guy told me that  
they
just installed a new firewall last week and I am waiting for a  
call
from thier primary IT guy (because he set this
up) to see if the problem could be on their end.
Questions...
Could the fact that some URLs did not have <@usereferenceargument>
and some did be a problem?
There are a few meta refreshes that go to a different page that  
did
not carry the <@usereferenceargument>, could this have been a
problem?
Could the fact that they are all coming to the site on just a few
IPs be a problem?
Could their firewall be a problem and what do I need to tell  
them to
get it to work correctly? Port 80, of course. Cookie enabled, of
course... am I missing something?
Sine I already worked on this for a couple of hours this  
morning, I
have yet to have them call me with any more problems. I guess I'll
have to wait and see if I already corrected any problems on my  
end.
What's wierd is that I have a couple of forums with well over 5000
users for each and I have never had any problems with any of these
when it comes to keeping users separate. I have never built  
anything
like this for users coming in on a limited
set of IP     addresses.
Any insight would be appreciated...
Thanks!
__________________________________________________________________ 
__
____ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/
maillist.taf

___________________________________________________________________ 
__
___ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/
maillist.taf
___________________________________________________________________ 
__
___ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/
maillist.taf

____________________________________________________________________ 
__
__ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/
maillist.taf
____________________________________________________________________ 
__
__ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/ 
maillist.taf
_____________________________________________________________________ 
___
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
_____________________________________________________________________ 
___
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf

_____________________________________________________________________ 
___
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf


______________________________________________________________________ 
__
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf

________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf