On Sun, 31 Aug 2008 16:11:10 +0100, "dE|_"
 wrote in
<swyuk.56786$OR5.20207@newsfe20.ams2>:

>I had tried a very simple page encryption software that uses javascript to 
>scramble up the entire page's HTML until login. This is something I can do 
>entirely on my own but is obviously risky for accessibility.
>
>Htaccess is one I tried, and works with no accessibility or cross-browser 
>issues, but is not pretty and the entry box does not sit in the page. That's 
>where we are now. It can sit in a form, but you need a script like php to 
>send the form details to the htaccess controller.
>Question answered, and you have suggested the php fetch.

If all you want to protect is a single HTTP resource then the answers
you have been given may be sufficient, but in my experience this
situation is rare.

It is much more common to want to create an authenticated session so
that the user can retrieve a number of protected HTML, CSS, image and
perhaps other resources after a single login rather than having to
repeat the login for each individual resource.

Browsers generally have a built in way to respond to the authentication
requests defined in the HTTP protocol and will issue the necessary
headers without user intervention after the initial dialogue where the
user gives the username and password to the browser. Note here the
important point that the browser needs to be given that information if
it is to include it in the HTTP protocol exchanges for subsequent
resource retrievals. None of the suggestions for server-side processing
of form data have included any information about how the browser obtains
the user credentials. I am not aware of any way in which a server side
mechanism can add a username and password to the set from which the
browser selects the appropriate pair when creating the 'Authorization'
header in an HTTP request.

It is these HTTP protocol authentication mechanisms that people often
inaccurately refer to as 'htaccess' (see the Apache httpd documentation
if you want an explanation of why I say 'inaccurately'.)

Note here that the choice of server side language is irrelevant. If
anyone can say what protocol exchange between browser and server can
download credentials for basic or digest authentication from server to
browser then the server side part can be coded in whatever language you
like.

-- 
Owen Rees
[one of] my preferred email address[es] and more stuff can be
found at <http://www.users.waitrose.com/~owenrees/index.html>

"Owen Rees" informed me kindly;
>
>>I had tried a very simple page encryption software that uses javascript to
>>scramble up the entire page's HTML until login. This is something I can do
>>entirely on my own but is obviously risky for accessibility.
>>
>>Htaccess is one I tried, and works with no accessibility or cross-browser
>>issues, but is not pretty and the entry box does not sit in the page. 
>>That's
>>where we are now. It can sit in a form, but you need a script like php to
>>send the form details to the htaccess controller.
>>Question answered, and you have suggested the php fetch.
>
> If all you want to protect is a single HTTP resource then the answers
> you have been given may be sufficient, but in my experience this
> situation is rare.
>
> It is much more common to want to create an authenticated session so
> that the user can retrieve a number of protected HTML, CSS, image and
> perhaps other resources after a single login rather than having to
> repeat the login for each individual resource.
>
> Browsers generally have a built in way to respond to the authentication
> requests defined in the HTTP protocol and will issue the necessary
> headers without user intervention after the initial dialogue where the
> user gives the username and password to the browser. Note here the
> important point that the browser needs to be given that information if
> it is to include it in the HTTP protocol exchanges for subsequent
> resource retrievals. None of the suggestions for server-side processing
> of form data have included any information about how the browser obtains
> the user credentials. I am not aware of any way in which a server side
> mechanism can add a username and password to the set from which the
> browser selects the appropriate pair when creating the 'Authorization'
> header in an HTTP request.
>
> It is these HTTP protocol authentication mechanisms that people often
> inaccurately refer to as 'htaccess' (see the Apache httpd documentation
> if you want an explanation of why I say 'inaccurately'.)
>
> Note here that the choice of server side language is irrelevant. If
> anyone can say what protocol exchange between browser and server can
> download credentials for basic or digest authentication from server to
> browser then the server side part can be coded in whatever language you
> like.

Thank you, I will keep that noted.

You speak of HTTP authentication only being apt for a single item rather 
than a session, when 'big brother' showed me how to set up htaccess on the 
server it was actually only for a low budget one-page site. A page holding a 
Flash mp3 player, available to industry/invite only.

Log-in, listen, send an email, leave. That may be why site-wide sessions 
never came in to conversation.

-dE|_---

On Mon, 1 Sep 2008 16:36:51 +0100, "dE|_"
 wrote in
<l_Tuk.137904$6s4.128929@newsfe14.ams2>:

>Thank you, I will keep that noted.
>
>You speak of HTTP authentication only being apt for a single item rather 
>than a session, when 'big brother' showed me how to set up htaccess on the 
>server it was actually only for a low budget one-page site. A page holding a 
>Flash mp3 player, available to industry/invite only.

It is the other way round.

HTML pages with embedded scripts that are decrypted by the browser
protect only themselves, not any subsequently retrieved resource, unless
the page also has scripts that handle the retrieval and decoding of
other resources or at the very least has some way to pass the
authorization data to subsequently retrieved self decoding pages (and I
don't think you can protect images, video etc like that).

If you have a form where the server side processing of the action takes
authentication data from the form and then, assuming the credentials are
good, just responds with the content of a resource without doing
anything else then it is only that one resource that is protected.

The HTTP protocol authentication is typically implemented in browsers in
such a way that the browser will automatically supply the authorization
data for subsequent requests for resources from the same realm without
troubling the user for a password. The authorization data generally
persists in the browser until the user explicitly deletes it or the
server ceases to accept the credentials because the username or password
have been revoked or changed at the server.

>Log-in, listen, send an email, leave. That may be why site-wide sessions 
>never came in to conversation.

Even in such a simple case you need to authorize multiple requests if
the resources are all protected. With the HTTP protocol mechanisms this
"just works" but only because both browser and server have been
implemented to make it so.

Most web form based authentication systems work by creating some session
authorization token and sending it back to the browser either as a
cookie or embedded in dynamically generated URLs in the returned
resources. The browser sends back the authorization data either in a
cookie or in the URL of the subsequent request without the user having
to do anything and the server then dynamically verifies the
authorization before returning each resource. Most people do not code
this for themselves, there are libraries you can use with a standard web
server or application servers and content management systems with it
already included.


-- 
Owen Rees
[one of] my preferred email address[es] and more stuff can be
found at <http://www.users.waitrose.com/~owenrees/index.html>

"Owen Rees"  wrote in message 
news:uenob4teod5ehsn8vk3ml7jgqc91q38trt@4ax.com...
> On Mon, 1 Sep 2008 16:36:51 +0100, "dE|_"
>  wrote in
> <l_Tuk.137904$6s4.128929@newsfe14.ams2>:
>
>>Thank you, I will keep that noted.
>>
>>You speak of HTTP authentication only being apt for a single item rather
>>than a session, when 'big brother' showed me how to set up htaccess on the
>>server it was actually only for a low budget one-page site. A page holding 
>>a
>>Flash mp3 player, available to industry/invite only.
>
> It is the other way round.
>
> HTML pages with embedded scripts that are decrypted by the browser
> protect only themselves, not any subsequently retrieved resource, unless
> the page also has scripts that handle the retrieval and decoding of
> other resources or at the very least has some way to pass the
> authorization data to subsequently retrieved self decoding pages (and I
> don't think you can protect images, video etc like that).
>
> If you have a form where the server side processing of the action takes
> authentication data from the form and then, assuming the credentials are
> good, just responds with the content of a resource without doing
> anything else then it is only that one resource that is protected.
>
> The HTTP protocol authentication is typically implemented in browsers in
> such a way that the browser will automatically supply the authorization
> data for subsequent requests for resources from the same realm without
> troubling the user for a password. The authorization data generally
> persists in the browser until the user explicitly deletes it or the
> server ceases to accept the credentials because the username or password
> have been revoked or changed at the server.
>
>>Log-in, listen, send an email, leave. That may be why site-wide sessions
>>never came in to conversation.
>
> Even in such a simple case you need to authorize multiple requests if
> the resources are all protected. With the HTTP protocol mechanisms this
> "just works" but only because both browser and server have been
> implemented to make it so.
>
> Most web form based authentication systems work by creating some session
> authorization token and sending it back to the browser either as a
> cookie or embedded in dynamically generated URLs in the returned
> resources. The browser sends back the authorization data either in a
> cookie or in the URL of the subsequent request without the user having
> to do anything and the server then dynamically verifies the
> authorization before returning each resource. Most people do not code
> this for themselves, there are libraries you can use with a standard web
> server or application servers and content management systems with it
> already included.

...okay, thanks. You kind of lost me a couple of branches ago, but I really 
apreciate your efforts here and the posts have been saved for reference.

-dE|_---