On Fri, Feb 8, 2008 at 7:24 AM, Michael Peters [EMAIL PROTECTED] wrote:
Stephen Carville wrote:
Seems to me it makes more sense to embed the session ID or any other
tracking as hidden variables in a form and send it back as a POST.
This assumes then that every request you make is now a
I've just come back to this thread as I'm just about to alter the
session handling in tha app that I'm working on. It currently uses
the url method, which I plan to replace.
I'm struggling to accept the form method, because as you say no more
a href=myapp.cgi?rm=next - unless of course we use
On Wed, Mar 5, 2008 at 4:47 AM, Mike Tonks [EMAIL PROTECTED] wrote:
I'm struggling to accept the form method, because as you say no more
a href=myapp.cgi?rm=next - unless of course we use javascript.
Now I like the old links, so cookies seems like a no brainer to me.
Can anyone explain
On Feb 6, 2008 3:39 PM, Dan Horne [EMAIL PROTECTED] wrote:
Mark Fuller said:
I thought the problem with putting the session ID in the URL is that
the user might copy/paste the URL to others. When they try to use it,
the app would have no way to know it's not the real user?
Another
This is an interesting thread, and XSS is something that I haven't
really understood. Let me see if I'm understanding this correctly:
Basically one version of an XSS attack would be for me to enter
javascript code into a form on your web page. Then if you include my
form submission in
Ron Savage wrote:
On Wed, 2008-02-06 at 17:16 -0500, Michael Peters wrote:
Hi Michael
This is why escaping any data that could potentially come from a user is so
important.
Not just escaping. OP should be warned that server code cannot just rely
on Javascript-base validation. Someone
Stephen Carville wrote:
Seems to me it makes more sense to embed the session ID or any other
tracking as hidden variables in a form and send it back as a POST.
This assumes then that every request you make is now a post request. Which means
not more a links, just forms. And this also breaks
o
From: Michael Peters
Sent: Saturday, 9 February 2008 4:28 a.m.
To: CGI Application
Subject: Re: [cgiapp] Persistence
Ron Savage wrote:
On Wed, 2008-02-06 at 17:16 -0500, Michael Peters wrote:
Hi Michael
This is why escaping any data that could potentially come from a user
Slightly offtopic plug... there's no extra work to do javascript validation
if using Data::FormValidator for your validation.
http://search.cpan.org/~markstos/Data-FormValidator-4.57/
http://developer.berlios.de/projects/formvalidatorjs/
Makes the user experience much better when they don't have
-Original Message-
From: Karen
Sent: Thursday, 7 February 2008 3:12 p.m.
To: CGI Application
Subject: Re: [cgiapp] Persistence
On 2/6/08, Dan Horne [EMAIL PROTECTED] wrote:
Another problem is bookmarks. A user may bookmark a page, but when they
come back a couple of days
On Wed, 2008-02-06 at 16:47 -0500, Michael Peters wrote:
Hi Michael
Maybe I'm being dense, but XSS is about letting user's embed HTML/JS into
other
Maybe I'm raving again. I was hoping OP could use XSS as a search key to
save me thinking. Perhaps I should have tried the search myself :-(.
On 2/6/08, Dan Horne [EMAIL PROTECTED] wrote:
Another problem is bookmarks. A user may bookmark a page, but when they
come back a couple of days later, the session has expired. They might also
email a link to others, and that link may not work for the same reason.
If you want a poster child
On Wed, 2008-02-06 at 17:16 -0500, Michael Peters wrote:
Hi Michael
This is why escaping any data that could potentially come from a user is so
important.
Not just escaping. OP should be warned that server code cannot just rely
on Javascript-base validation. Someone might disable Javascript
On top of the other responses, I'd add:
Your application must keep track of a 'session'. The main ways to do
that are:
o Add a hidden field to each CGI form, in which you send out to the
client the id of their session, so that when the use submits the form
you get back their id. This is my
On Wed, 2008-02-06 at 08:16 +, Mark Knoop wrote:
Hi Mark
On top of the other responses, I'd add:
Your application must keep track of a 'session'. The main ways to do
that are:
o Add a hidden field to each CGI form, in which you send out to the
client the id of their session,
Ron Savage wrote:
o Add the session id to the URL. This method has the most problems, and
is not recommended.
The session id is generated by CGI::Session.
Surely 1 and 3 are the same (except possibly you are talking about a post vs
get)?
Not really.
What are the problems with the
o Add the session id to the URL. This method has the most problems, and
is not recommended.
What are the problems with the last option? ...
Google for XSS - Cross-site scripting attacks, as a starter.
I thought the problem with putting the session ID in the URL is that
the user might
Mark Fuller wrote:
o Add the session id to the URL. This method has the most problems, and
is not recommended.
What are the problems with the last option? ...
Google for XSS - Cross-site scripting attacks, as a starter.
I thought the problem with putting the session ID in the URL is that
Mark Fuller said:
I thought the problem with putting the session ID in the URL is that
the user might copy/paste the URL to others. When they try to use it,
the app would have no way to know it's not the real user?
Another problem is bookmarks. A user may bookmark a page, but when they
come
Hi
I'm new to CGI::Application.
I like the way it makes me organize the script but I guess I could do it in
this way without CGI:Application so I just want to be sure I fully
understand the benefits.
Given that I am not running it under mod_perl at this stage is each instance
request a
Hi
I'm new to CGI::Application.
I like the way it makes me organize the script but I guess I could do it
in this way without CGI:Application so I just want to be sure I fully
understand the benefits.
Given that I am not running it under mod_perl at this stage is each
instance request a
On Feb 5, 2008 10:59 PM, Mark Knoop [EMAIL PROTECTED] wrote:
Hi
I'm new to CGI::Application.
Welcome
I like the way it makes me organize the script but I guess I could do it
in this way without CGI:Application so I just want to be sure I fully
understand the benefits.
Given that
Bottomline, CGI::App does lots of the work for you. Life is easier. I
could not develop for the Web without it.
Brad
On Feb 5, 2008 4:44 AM, Mark Knoop [EMAIL PROTECTED] wrote:
Hi
I'm new to CGI::Application.
I like the way it makes me organize the script but I guess I could do it in
this
On Feb 5, 2008 10:59 PM, Mark Knoop [EMAIL PROTECTED] wrote:
Hi
I'm new to CGI::Application.
Welcome
I like the way it makes me organize the script but I guess I could do
it
in this way without CGI:Application so I just want to be sure I fully
understand the benefits.
Given that
On Tue, 2008-02-05 at 10:44 +, Mark Knoop wrote:
Hi Mark
I have read through lots of docs but I seem to be missing this key point...
if there is a doc specifically related to this that would be a huge help.
On top of the other responses, I'd add:
Your application must keep track of a
25 matches
Mail list logo
