Elliotte Harold wrote:
Kenneth Downs wrote:
True, but we need a better answer than that.
Can you explain what mechanisms are storing the passwords, and why no
additional weakness has been introduced?
The issue here is really one of psychology and usability. A poorly
usable authentication
Daniel Convissor wrote:
Except having a password store on one's computer that's separate from the
browser. There are several pieces of software that do this.
If that's integrated with the browser, sure. However if it's not, it's
too complicated. Opening a separate app, typing in its password
On Sat, Sep 22, 2007 at 12:23:21PM -0400, Elliotte Harold wrote:
>
> Thus the only
> choice is to place this repository on the client.
> ... snip ...
> That means the
> browser itself (or a plug-in integrated into the browser) remembers the
> password.
>
> EVERYTHING ELSE THAT HAS BEEN TRIED TO
Kenneth Downs wrote:
True, but we need a better answer than that.
Can you explain what mechanisms are storing the passwords, and why no
additional weakness has been introduced?
The issue here is really one of psychology and usability. A poorly
usable authentication system will cause users
Hi Elliotte:
On Sat, Sep 22, 2007 at 08:19:01AM -0400, Elliotte Harold wrote:
>
> For basic I'd use encrypted connections only. Digest is fine in the
> "clear".
No HTTP auth method is okay in the clear. Digest sends an MD5 hash as
the token. While that doesn't tell me what your password is,
Elliotte Harold wrote:
Plus I don't like the idea of keeping authentication information in
the browser.
Tough. That's being done anyway.
True, but we need a better answer than that.
Can you explain what mechanisms are storing the passwords, and why no
additional weakness has been introduce
Daniel Convissor wrote:
Basic and Digest auth are slow when it comes to dealing with large user
bases.
I've seen no evidence of that whatsoever.
They also increase insecurity, particularly when working over
non-encrypted connections.
For basic I'd use encrypted connections only. Digest
Hi Elliotte:
On Wed, Sep 19, 2007 at 05:48:25AM -0400, Elliotte Harold wrote:
>
> However the fundamental principle is that full auth data must be sent
> with each request.
>
> Breaking that rule is going to cost you big time when you need to scale
> an application.
Basic and Digest auth are s
Elliotte Harold wrote:
Kenneth Downs wrote:
That can only be done if the password is stored on the browser
between requests. No thanks!
I don't know about your browser but mine (and those of most of the
people I know) store lots of passwords pretty much all the time. I
prefer to trust Fire
Elliotte Harold wrote:
Daniel Convissor wrote:
On Fri, Sep 07, 2007 at 07:40:50AM -0400, Elliotte Harold wrote:
Nonetheless, the username and password should be transmitted with
each request (in the HTTP header, not the URL)
Are you saying the web browser should send the user name and passwor
Daniel Convissor wrote:
On Fri, Sep 07, 2007 at 07:40:50AM -0400, Elliotte Harold wrote:
Nonetheless, the username and password should be transmitted with each
request (in the HTTP header, not the URL)
Are you saying the web browser should send the user name and password to
the HTTP server on
tedd wrote:
My solution is to simply require them to log-in and set a session auth
variable to OK and turn them loose. Then they have access to all the
goodies.
While what they ask for on the site is provided in the URL via a GET,
and as such, they could bookmark it and/or send the URL to so
Kenneth Downs wrote:
That can only be done if the password is stored on the browser between
requests. No thanks!
I don't know about your browser but mine (and those of most of the
people I know) store lots of passwords pretty much all the time. I
prefer to trust Firefox's encryption and sec
On Fri, Sep 07, 2007 at 07:40:50AM -0400, Elliotte Harold wrote:
>
> Nonetheless, the username and password should be transmitted with each
> request (in the HTTP header, not the URL)
Are you saying the web browser should send the user name and password to
the HTTP server on each request? That
Elliotte Harold wrote:
David Krings wrote:
But isn't that the old GET that has so many limitations that many web
app design guides basically tell you not to use it?
I have no idea what you're talking about. GET is GET. There's no old GET
and new GET that I've ever heard of.
Bad wording on
On Sep 7, 2007, at 7:01 AM, Elliotte Harold wrote:
Kenneth Downs wrote:
Elliotte Harold wrote:
http://www.google.com/search?q=Ken+Downs&hl=en&start=10&sa=N
Did you log into Google?
Checking the screen it looks I was logged in
So... how did Google know you were logged in? Look at your cooki
[EMAIL PROTECTED] wrote:
Kenneth Downs wrote:
That can only be done if the password is stored on the browser
between requests. No thanks!
At any rate, in principle I believe that sessions are a bad way to do
things, they just have that bag-on-the-side feel. The only permanent
use of a sessio
Kenneth Downs wrote:
That can only be done if the password is stored on the browser between
requests. No thanks!
At any rate, in principle I believe that sessions are a bad way to do
things, they just have that bag-on-the-side feel. The only permanent
use of a session in Andromeda is to store
At 6:16 AM -0400 9/7/07, Elliotte Harold wrote:
tedd wrote:
From many of the post here, I thought someone had discovered something new.
Discovering something truly new is rare. There's almost always
someone who discovered it before you. Sometimes we don't believe
them, though, until we dis
Elliotte Harold wrote:
Kenneth Downs wrote:
Should I email you a link allowing you to log into my customer's
application and view confidential medical information?
Nonetheless, the username and password should be transmitted with each
request (in the HTTP header, not the URL) so that it d
Kenneth Downs wrote:
Should I email you a link allowing you to log into my customer's
application and view confidential medical information?
User authentication is (usually) separate from the URL. You can e-mail
me such a link if you wish, but without the username and password I
wouldn't
David Krings wrote:
But isn't that the old GET that has so many limitations that many web
app design guides basically tell you not to use it?
I have no idea what you're talking about. GET is GET. There's no old GET
and new GET that I've ever heard of.
It's certainly true that there are a l
Elliotte Harold wrote:
Kenneth Downs wrote:
Elliotte Harold wrote:
Which is exactly why we don't use sessions for such applications.
Instead the page of "next" search results is a URL like
http://www.google.com/search?q=Ken+Downs&hl=en&start=10&sa=N
Did you log into Google?
Checking
Elliotte Harold wrote:
Which is exactly why we don't use sessions for such applications.
Instead the page of "next" search results is a URL like
http://www.google.com/search?q=Ken+Downs&hl=en&start=10&sa=N
That's an actual Google "Next" URL. It still works even though I've
pasted it into an e
Kenneth Downs wrote:
Elliotte Harold wrote:
Which is exactly why we don't use sessions for such applications.
Instead the page of "next" search results is a URL like
http://www.google.com/search?q=Ken+Downs&hl=en&start=10&sa=N
Did you log into Google?
Checking the screen it looks I wa
Elliotte Harold wrote:
tedd wrote:
From many of the post here, I thought someone had discovered
something new.
Discovering something truly new is rare. There's almost always someone
who discovered it before you. Sometimes we don't believe them, though,
until we discover it for ourselves.
Elliotte Harold wrote:
Which is exactly why we don't use sessions for such applications.
Instead the page of "next" search results is a URL like
http://www.google.com/search?q=Ken+Downs&hl=en&start=10&sa=N
Did you log into Google?
--
Kenneth Downs
Secure Data Software, Inc.
www.secdat.com
Dell Sala wrote:
=
The problem with what you're describing is that all your form validation
code (business logic) is deployed to the browser as javascript. For
serious applications, the server cannot rely on the client to take care
of things like validation, because they can easily be bypassed.
tedd wrote:
From many of the post here, I thought someone had discovered something
new.
Discovering something truly new is rare. There's almost always someone
who discovered it before you. Sometimes we don't believe them, though,
until we discover it for ourselves.
Interestingly though
Kenneth Downs wrote:
One thing that seems to have gone unsaid in the praise for Ajax is its
ability to radically transform how we maintain state.
The web server session is our basic mechanism for storing information
between requests. But it gets clumsier and clumsier to try to maintain
compl
tedd wrote:
At 9:35 PM -0400 9/5/07, John Campbell wrote:
> The beginning of this thread led me to suspect that someone had found
a way to move data from one browser window to another and I was
focusing in on that, but that turned to be false.
What makes you think you can't move stuff from
At 9:35 PM -0400 9/5/07, John Campbell wrote:
> The beginning of this thread led me to suspect that someone had found
a way to move data from one browser window to another and I was
focusing in on that, but that turned to be false.
What makes you think you can't move stuff from one window t
> The beginning of this thread led me to suspect that someone had found
> a way to move data from one browser window to another and I was
> focusing in on that, but that turned to be false.
What makes you think you can't move stuff from one window to another?
It is completely possible so long as e
At 7:47 PM -0400 9/5/07, Steve Manes wrote:
tedd wrote:
Now, what I am asking is not how ajax communication with the server
can be used, but rather is there anything beyond that which ajax
can provide?
Another way of asking this question is, "Besides not triggering a
refresh, what can ajax d
tedd wrote:
Now, what I am asking is not how ajax communication with the server can
be used, but rather is there anything beyond that which ajax can provide?
Another way of asking this question is, "Besides not triggering a
refresh, what can ajax do that php can not?"
You're right: nothing.
tedd wrote:
My slant, which is of no importance, is that web application
developers have to be masters of several languages -- one won't do. At
present, a good grasp of php, javascript, mysql, css, and ajax makes
for good company in application development.
Hmm...has this ever not been t
At 12:07 PM -0400 9/5/07, Gary Mort wrote:
tedd wrote:
Another way of asking this question is, "Besides not triggering a
refresh, what can ajax do that php can not?"
PHP cannot control the browser presentation, it can merely provide
static information to the browser.
Ah yes, my question w
At 11:52 AM -0400 9/5/07, Dell Sala wrote:
On Sep 5, 2007, at 11:20 AM, tedd wrote:
Just keep the user entering data until the data is correct, then
submit the form via ajax or as one normally would via a form submit.
So, I don't see the ajax advantage here.
The problem with what you're des
tedd wrote:
Another way of asking this question is, "Besides not triggering a
refresh, what can ajax do that php can not?"
PHP cannot control the browser presentation, it can merely provide
static information to the browser.
Javascript can control the browser presentation, and it can be gene
At 11:33 AM -0400 9/5/07, Dell Sala wrote:
On Sep 5, 2007, at 11:08 AM, tedd wrote:
Now, what I am asking is not how ajax communication with the server
can be used, but rather is there anything beyond that which ajax
can provide?
Another way of asking this question is, "Besides not triggerin
On Sep 5, 2007, at 11:20 AM, tedd wrote:
Just keep the user entering data until the data is correct, then
submit the form via ajax or as one normally would via a form submit.
So, I don't see the ajax advantage here.
The problem with what you're describing is that all your form
validation
At 9:47 AM -0400 9/5/07, Gary Mort wrote:
tedd wrote:
Please correct me if I'm wrong, but isn't ajax (and ahah) only a
means to communicate with the server without causing a refresh?
Does ajax provide something beyond that?
Ajax changes the way you program. Consider the following:
You have a
On Sep 5, 2007, at 11:08 AM, tedd wrote:
Now, what I am asking is not how ajax communication with the server
can be used, but rather is there anything beyond that which ajax
can provide?
Another way of asking this question is, "Besides not triggering a
refresh, what can ajax do that php c
At 9:31 AM -0400 9/5/07, Kenneth Downs wrote:
tedd wrote:
At 8:20 AM -0400 9/5/07, [EMAIL PROTECTED] wrote:
Hans Zaunere wrote:
Ajax solves this problem neatly by letting you move all state [1] into
the browser. This makes sense from an architectural viewpoint because
we are putting this con
At 9:40 AM -0400 9/5/07, Mark Armendariz wrote:
tedd wrote:
At 8:20 AM -0400 9/5/07, [EMAIL PROTECTED] wrote:
Hans Zaunere wrote:
Ajax solves this problem neatly by letting you move all state [1] into
the browser. This makes sense from an architectural viewpoint because
we are putting this c
Hans Zaunere wrote:
Ajax solves this problem neatly by letting you move all state [1] into
the browser. This makes sense from an architectural viewpoint because
we are putting this context information close to where it is needed,
the UI.
I'm not sure what you mean, though, by keeping s
[EMAIL PROTECTED] wrote:
Kenneth Downs wrote:
BZ's example is exactly what I've been coding the past week or so,
and it is far simpler keeping track
^
I'll take this as a hint that I need to create a sigfile with my name
and such in it.
Unless you've got secrets to keep :)
Kenneth Downs wrote:
BZ's example is exactly what I've been coding the past week or so, and
it is far simpler keeping track
^
I'll take this as a hint that I need to create a sigfile with my name
and such in it.
___
New York PHP Community Tal
tedd wrote:
At 8:20 AM -0400 9/5/07, [EMAIL PROTECTED] wrote:
I read the above as, to take a simple example:
I read your "simple example" and see that you can do it w/wo ajax --
but I don't see the advantage in using ajax other than presentation.
To do it without Ajax requires you to exp
tedd wrote:
At 8:20 AM -0400 9/5/07, [EMAIL PROTECTED] wrote:
Hans Zaunere wrote:
Ajax solves this problem neatly by letting you move all state [1] into
the browser. This makes sense from an architectural viewpoint because
we are putting this context information close to where it is needed,
t
tedd wrote:
At 8:20 AM -0400 9/5/07, [EMAIL PROTECTED] wrote:
Hans Zaunere wrote:
Ajax solves this problem neatly by letting you move all state [1] into
the browser. This makes sense from an architectural viewpoint because
we are putting this context information close to where it is needed,
t
At 8:20 AM -0400 9/5/07, [EMAIL PROTECTED] wrote:
Hans Zaunere wrote:
Ajax solves this problem neatly by letting you move all state [1] into
the browser. This makes sense from an architectural viewpoint because
we are putting this context information close to where it is needed,
the UI.
I'm
Hans Zaunere wrote:
Ajax solves this problem neatly by letting you move all state [1] into
the browser. This makes sense from an architectural viewpoint because
we are putting this context information close to where it is needed,
the UI.
I'm not sure what you mean, though, by keeping sta
Hi,
Kenneth Downs wrote on Tuesday, September 04, 2007 8:51 AM:
> One thing that seems to have gone unsaid in the praise for Ajax is its
> ability to radically transform how we maintain state.
>
> The web server session is our basic mechanism for storing information
> between requests. But it g
I have not looked at Dojo yet, though they have been on "the list" for
awhile.
The firefox extensions are now looking really exciting. I am looking to
download or write an extension that will let me ship photographs from a
camera directly to the database, and also to intercept bar code scans
Personally ... I think even broader ideas like Dojo Offline (http://
dojotoolkit.org/offline) and Google Gears (http://gears.google.com/)
takes it to an even further level which has not been tapped (yet).
Now if only you can sneak it into a project ;-)
- Jon
On Sep 4, 2007, at 8:50 AM, Ken
One thing that seems to have gone unsaid in the praise for Ajax is its
ability to radically transform how we maintain state.
The web server session is our basic mechanism for storing information
between requests. But it gets clumsier and clumsier to try to maintain
complex state across many p
57 matches
Mail list logo
