Barry Moore wrote:
> 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 other web pages then my javascript could execute on
> any other users machine that subsequently loaded those tainted pag
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?
> >
>
>
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
Hi Mike,
My preferred way is to simply call the view runmode after the update has
completed. That way you can pass variable or parameters back to the view
to prompt a message to be displayed.
e.g.
sub update {
my $self = shift;
# update the record
...
# set a message to be displa
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
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
Hi
I would be grateful if someone could offer me some guidance.
When I started thinking about reorganising my app with CGI::Application but
before I knew much about it I thought it would be good to have a Globals
object which I set up when the script is called which stores all the things
I ne
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
Sorry for the second post. I decided that this topic has diverged
enough it should be a separate thread. Reply to this one instead if
you see it in time.
This is an interesting thread, and XSS is something that I haven't
really understood. Let me see if I'm understanding this correctly:
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
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 c
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
> -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 coup
Thanks Michael - that helps clear things up for me.
B
On Feb 8, 2008, at 8:40 AM, Michael Peters wrote:
Barry Moore wrote:
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 other web pages
Greetings,
CHI, if you haven't heard of it already, is a new caching framework by
Jonathan Swartz designed to eventually replace Cache::Cache.
http://search.cpan.org/~jswartz/CHI-0.05/lib/CHI.pm
I am currently soliciting ideas for features that people would like to
see in a CGI-App plugin for
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
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 Thu, 2008-02-07 at 10:34 +, Mark Knoop wrote:
Hi Mark
> Also I see that CGI::Application has its own params - am I right in thinking
> these are completeley different to the query params? Is there any
> relationship between the two? Should I just be using these for 'global'
> values?
>
Mark Knoop wrote in an email message dated 2/7/2008 5:34 AM:
> Also I see that CGI::Application has its own params - am I right in
> thinking these are completeley different to the query params? Is there
> any relationship between the two? Should I just be using these for
> 'global' values?
20 matches
Mail list logo
