Till Maas wrote:
On Wed November 26 2008, Toshio Kuratomi wrote:
Till Maas wrote:
How big the regression is if users have to log in for every external link
they click on, depends on how often this happens. I believe that links to
FAS are not exchanged very often, therefore it will not hurt
On Wed November 26 2008, Toshio Kuratomi wrote:
Till Maas wrote:
On Wed November 26 2008, Toshio Kuratomi wrote:
To be easy to code, require the token for every request of an
authenticated user.
If I understand your proposal correctly, a user would need to login again
for every link
On Wed, Nov 26, 2008 at 04:53:00PM +0100, Till Maas wrote:
How big the regression is if users have to log in for every external link
they
click on, depends on how often this happens. I believe that links to FAS are
not exchanged very often, therefore it will not hurt very much. I guess
Chuck Anderson wrote:
On Wed, Nov 26, 2008 at 04:53:00PM +0100, Till Maas wrote:
How big the regression is if users have to log in for every external link
they
click on, depends on how often this happens. I believe that links to FAS are
not exchanged very often, therefore it will not hurt
Till Maas wrote:
On Wed November 26 2008, Toshio Kuratomi wrote:
Till Maas wrote:
On Wed November 26 2008, Toshio Kuratomi wrote:
To be easy to code, require the token for every request of an
authenticated user.
If I understand your proposal correctly, a user would need to login again
for
On Wed, Nov 26, 2008 at 09:47:06AM -0800, Toshio Kuratomi wrote:
Pretty much agreed on this analysis. My one note is that in my usage,
at least, I already have to login most of the time when clicking on a
link in bugzilla or email due to my session having expired already.
Stange. I almost
On Wed November 26 2008, Toshio Kuratomi wrote:
Till Maas wrote:
How big the regression is if users have to log in for every external link
they click on, depends on how often this happens. I believe that links to
FAS are not exchanged very often, therefore it will not hurt very much. I
On Mon November 24 2008, Toshio Kuratomi wrote:
I've been researching the CSRF exploit and how it affects our web apps
recently. The short story is that our code is pretty open to this at
the moment. I've written up a proposal for fixing this but it will
require a lot of coding so I'd love
I've read the document and it is pretty well thought out. A couple of comments
- for the JavaScript parts wouldn't that be better to setup as an included file
which also pulls in a JS library? Just so people aren't copying and pasting?
That way you will also be able to extend the
John Palmieri wrote:
I've read the document and it is pretty well thought out. A couple of
comments - for the JavaScript parts wouldn't that be better to setup as an
included file which also pulls in a JS library? Just so people aren't
copying and pasting? That way you will also be able
On Tue November 25 2008, Mike McGrath wrote:
GET vs POST is an interesting discussion. From a security point of view
though the only advantage is in how we log and that GET requests stay in
the logs.
There may be also some other issues, e.g. when GET requests are used to submit
confidential
Till Maas wrote:
On Tue November 25 2008, Mike McGrath wrote:
GET vs POST is an interesting discussion. From a security point of view
though the only advantage is in how we log and that GET requests stay in
the logs.
There may be also some other issues, e.g. when GET requests are used to
On Tue November 25 2008, Toshio Kuratomi wrote:
Till Maas wrote:
It is recommended to not use GET requests to change state on the server,
therefore it would be probably better to change these GET requests to
POST requests.
The proposal doesn't specifically mention POST there as well but
Till Maas wrote:
On Tue November 25 2008, Toshio Kuratomi wrote:
Till Maas wrote:
It is recommended to not use GET requests to change state on the server,
therefore it would be probably better to change these GET requests to
POST requests.
The proposal doesn't specifically mention POST
On Tue November 25 2008, Toshio Kuratomi wrote:
For these issues we could either concentrate on fixing or mitigating
them. Fixing them would require the laborious changes I talked about
earlier to change the way the framework already processes the POST and
GET parameters before they get to
Till Maas wrote:
On Tue November 25 2008, Toshio Kuratomi wrote:
For these issues we could either concentrate on fixing or mitigating
them. Fixing them would require the laborious changes I talked about
earlier to change the way the framework already processes the POST and
GET parameters
Till Maas wrote:
On Wed November 26 2008, Toshio Kuratomi wrote:
To be easy to code, require the token for every request of an
authenticated user.
If I understand your proposal correctly, a user would need to login again for
every link he clicks from his bookmarks or any mail he gets
Greetings all,
I've been researching the CSRF exploit and how it affects our web apps
recently. The short story is that our code is pretty open to this at
the moment. I've written up a proposal for fixing this but it will
require a lot of coding so I'd love to have some more eyes on it to make
On Mon, 24 Nov 2008, Toshio Kuratomi wrote:
Greetings all,
I've been researching the CSRF exploit and how it affects our web apps
recently. The short story is that our code is pretty open to this at
the moment. I've written up a proposal for fixing this but it will
require a lot of coding
On Mon, 24 Nov 2008, Mike McGrath wrote:
This is well reasoned and inciteful. After F10 ships I've got a couple of
things in the pipe to flush out but after that I'll work with you to get
the major issues fixed as quickly as possible.
Ugh, inciteful? really? You'd think I'd spell check
On Mon, Nov 24, 2008 at 03:30:03PM -0600, Mike McGrath wrote:
On Mon, 24 Nov 2008, Mike McGrath wrote:
This is well reasoned and inciteful. After F10 ships I've got a couple of
things in the pipe to flush out but after that I'll work with you to get
the major issues fixed as quickly as
21 matches
Mail list logo
