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
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
> - unless of course we use javascript.
>
> Now I like the old links, so cookies seems like a no brainer to me.
> Can anyone explain why the form metho
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
- unless of course we use javascript.
Now I like the
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
> >
> >
> -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
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 t
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 validatio
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?
> >
>
>
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 links, just forms. And this also breaks RE
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 oth
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
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 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 :-(.
E
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 chi
Dan Horne said:
> 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 bookmar
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
co
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 th
> > > 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
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 p
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 the
>
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 pre
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 's
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
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.
>
> G
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.
>
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 comp
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 comp
27 matches
Mail list logo