Hi Bill,
When I want to join (Using MSSQL) across databases I use the Direct DBMS
in Witango. Works just fine. I figure if I can do it in a direct DMBS
that a standard select statement should do it as well. I mean, it's just
generating the SQL code so if it can link between tables in the same
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
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
Session cookies are easier to set in assignment actions. View properties
on the assignment action and you'll see the needed options there.
Stefan
At 10:21 AM 9/26/2007, you wrote:
Okay... I need a cookie education then, I guess.
I use cookies on some of my forums strictly to remember just a
I'm thinking you really mean to be using user scope variables rather
than cookies.
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
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
That's very important, because the precedence of the user key was
changed from T2000 to W5.
But I think it's your app logic, not the userkey (cookie or
@userreferenceargument:
You say that you can log in as two distinct users using the same
session key (cookie). You gave one example of
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
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
I'll have to echo this advise. It solved our problems! Come to think of it,
it was probably Jesse that taught me this eons ago...
:D
--
Beverly VothTier3 Data Web Services Group, LLC
606-864-0041 http://www.tier3web.com/xml.htm
Web Design Hosting *
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
My experience has been basically identical to Jesse's.
Plus, from very early days with Tango 4, once I figured out how to control my
HTTP headers I never used the @USERREFERENCEARGUMENT in any of my
applications - and the ones that are still running today are without issue.
When NOT using
Thanks guys. And yes, I found hundreds of posts on cookies in some of the
old Tango and Witango threads. I actually learned quite a bit.
As for upgrading, its not in the cards this week... However, you all make a
good point and an upgrade is going to have to come soon ;-) I need to get
things
Hi John,
Yes, but just make sure there are no line-breaks inside the value attribute
(other than the @CRLF's).
All the best.
Scott,
On Wed, September 26, 2007 3:17 pm, WebDude [EMAIL PROTECTED] said:
Thanks guys. And yes, I found hundreds of posts on cookies in some of the
old Tango and
you might want to throw a @purgeresults just in front of that and
place it in its own results action and make sure it is the first
action that the taf see to ensure no other header gets sent
Ben
On Sep 26, 2007, at 11:17 AM, WebDude wrote:
Thanks guys. And yes, I found hundreds of posts on
Okay... I will give this a shot.
As a side note, their IT guy verified that they were caching pages on their
end. He configured their firewall to not cache any requests from the site's
IP or domain. I am going to add this httpheader change too and see what
happens.
I'll keep you all posted.
And
How do I do that? Like this?...
@purgeresults@ASSIGN local$httpHeader VALUE=Content-Type:
text/html@CRLFCache-Control: no-cache, max-age=0, must-revalidate,
proxy-revalidate@CRLFPragma:
no-cache@CRLF@USERREFERENCECOOKIE@CRLF
-Original Message-
From: Ben Johansen [mailto:[EMAIL
you could also add to the url at the end
r=@random 999 999
this helps to thwart cache
Ben
On Sep 26, 2007, at 11:39 AM, WebDude wrote:
Okay... I will give this a shot.
As a side note, their IT guy verified that they were caching pages on
their
end. He configured their firewall to not
yes
you also need to make sure that there are 2 CRLF's at the end,
so you either add another @CRLF to this and clear white space after
(put cursor at end and hit delete a bunch ;-)
or
leave as is and delete all white space at end and then hit CRLF once.
Ben
On Sep 26, 2007, at 11:40 AM,
Well, now I am confused. I have this in a text file right now, all on one
line. Are you saying I should add another @CRLF at the end and then make
sure I clear all the whitespace? So it would look like this? (no line
breaks)...
@purgeresults@ASSIGN local$httpHeader VALUE=Content-Type:
yeah,
in html pages sent out there has to be a blank line starting with
CRLF between Header and Content
since you are making the header you need to provide the blank line.
that is what the 2nd CRLF does
Ben
On Sep 26, 2007, at 12:22 PM, WebDude wrote:
Well, now I am confused. I have this in
Okay Ben and Scott,
I added the header change to several pages and checked it with a header
checker. Status 200 with no errors and I see the values I changed...
HTTP/1.1 200 OK =
Server = Microsoft-IIS/5.0
Date = Wed, 26 Sep 2007 19:53:20 GMT
X-Powered-By = ASP.NET
Content-Type = text/html
Hi John,
Remove the last @CRLF.
If you read the Witango documentation, the @USERREFERENCECOOKIE metatag already
includes a @CRLF.
My original code was correct.
Scott,
On Wed, September 26, 2007 4:26 pm, Ben Johansen [EMAIL PROTECTED] said:
yeah,
in html pages sent out there has to be a
Sorry,
didn't mean any implication, just that the dbl crlf are needed
that is good to know on the userrefcookie
Ben
On Sep 26, 2007, at 1:07 PM, Scott Cadillac wrote:
Hi John,
Remove the last @CRLF.
If you read the Witango documentation, the @USERREFERENCECOOKIE
metatag already includes a
No problem Ben,
I had done my homework on this one a long time ago.
This number of line-returns is important, because although html output will
accept more than 2 line-returns between the HTTP header and the content, binary
and some xml (ajax) output will not.
Hope you're doing well buddy.
I have movies in a directory outside the Web-Root.
How can Witango load this mowies for playing.
I don't like to use as file storage http.//webroot/dir/file...
I like only to use the fixed path like C:\\dir\mowie.avi otherwise everybody
can read the path...
Any suggestions ?
regards
Daniel
We're running 5.5.0020, and having an issue with inserting UTF8 from
an Ajax front end into the database via Witango.
Witango appears to be converting the double byte characters into two
Latin1 characters, which breaks things.
Does anyone have a way of handling this?
Thanks,
Jason.
Try having the ajax front end, base64 the text before it gets to
witango, and have the DB decode the base64 on insert. I have spent
years working through text encoding issues, especially witango.
I think there is also a new version of the server, or maybe its in
020, there is a
28 matches
Mail list logo
