You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by "Park, Sung-Gu" <je...@thinkfree.com> on 2000/12/05 20:09:22 UTC

parseStatusLine? and Authorization?

1)
For status-line tokenizing, it's used StringTokenizer as default Constructor.
But It's wrong.  the third parameter of the StatusLine is allowed to use a space.
The quick pactch for this is below:

       statusText = statusLine.substring(13);
        /*
        try {
            //statusText = st.nextToken();
        } catch (NoSuchElementException ignored) {
        }
        */


2)
I have a suggestion. 
For interoperability,  Authorization Header is required for COPY, MOVE, UNLOCK, etc...
How will it be going with this?   I think It's important...  even though TC4 is not supported.



Authenticator.java

Posted by "Park, Sung-Gu" <je...@thinkfree.com>.
It's my digest scheme patch for  Authorization.


============================================

public class Authenticator {


    protected static Base64 base64 = new Base64();


    public static String challengeResponse(String challenge,
                                           Credentials credentials)
        throws WebdavException {

        if (challenge.startsWith("Basic")) {
            return basic(credentials);
        } else if (challenge.startsWith("Digest")) {
            throw new WebdavException("Unable to authenticate for Digest");
        }
        return null;

    }

    public static String challengeResponse(String challenge,
                                           Credentials credentials,
                                           String path)
        throws WebdavException {

        if (challenge.startsWith("Basic")) {
            return basic(credentials);
        } else if (challenge.startsWith("Digest")) {
            int indx = challenge.indexOf("realm");
// FIX ME: in the secure communication, it's possbile to have a problem.
            String realm = challenge.substring(indx);
            return digest(credentials, realm, path);
        }
        return null;
    }


    public static String digest(Credentials credentials, String realm,
                                String path) {

        String authString =
            "Digest username=\"" + credentials.getUserName() + "\", " +
            "realm=\"" + realm + "\", nonce=\"...\", " +
            "uri=\"" + path + "\", " +
            "response=\"...\", opaque=\"...\"";

        return authString;
    }

<snip>



Re: Header and HeaderElement

Posted by "Park, Sung-Gu" <je...@thinkfree.com>.
There is no order.  Even though it's not important.


----- Original Message ----- 
From: "B.C. Holmes" <bc...@roxton.com>
To: <sl...@jakarta.apache.org>
Sent: Thursday, December 07, 2000 1:15 PM
Subject: Re: Header and HeaderElement


> Remy Maucherat wrote:
> > 
> > I'll probably get rid of the current Header class, and replace it with the
> > HeaderElement class (actually, HeaderElement will become Header).
> > 
> > The only thing which will be changed is NameValuePair.toString(), which
> > would have to do what Header.toString() is doing. Header and NameValuePair
> > have the same API, so it shouldn't break anything (except I'll have to
> > replace HeaderElement by Header in the code).
> > 
> > Is it ok with you BC ?
> 
>      That's fine by me, although right now, the HeaderElement really
> only models the value part of the Header.  I'd had, in the back of my
> mind, a plan to turn Header into a subclass of NameValuePair with an
> overload on toString(), but your approach also works.
> 
> BCing you
> -- 
> B.C. Holmes             \u2625               http://www.bcholmes.org/
> "How often has somebody sensed they were needed without being told?
>  When you have a hurt in your heart you're too proud to disclose
>  Look over there... look over there...  Somebody always knows."
>                   - _La Cage aux Folles_
> 

Re: Header and HeaderElement

Posted by "B.C. Holmes" <bc...@roxton.com>.
Remy Maucherat wrote:
> 
> I'll probably get rid of the current Header class, and replace it with the
> HeaderElement class (actually, HeaderElement will become Header).
> 
> The only thing which will be changed is NameValuePair.toString(), which
> would have to do what Header.toString() is doing. Header and NameValuePair
> have the same API, so it shouldn't break anything (except I'll have to
> replace HeaderElement by Header in the code).
> 
> Is it ok with you BC ?

     That's fine by me, although right now, the HeaderElement really
only models the value part of the Header.  I'd had, in the back of my
mind, a plan to turn Header into a subclass of NameValuePair with an
overload on toString(), but your approach also works.

BCing you
-- 
B.C. Holmes             \u2625               http://www.bcholmes.org/
"How often has somebody sensed they were needed without being told?
 When you have a hurt in your heart you're too proud to disclose
 Look over there... look over there...  Somebody always knows."
                  - _La Cage aux Folles_

Header and HeaderElement

Posted by Remy Maucherat <re...@apache.org>.
Hi,

I'll probably get rid of the current Header class, and replace it with the
HeaderElement class (actually, HeaderElement will become Header).

The only thing which will be changed is NameValuePair.toString(), which
would have to do what Header.toString() is doing. Header and NameValuePair
have the same API, so it shouldn't break anything (except I'll have to
replace HeaderElement by Header in the code).

Is it ok with you BC ?

Remy


Basic Auth.

Posted by "Park, Sung-Gu" <je...@thinkfree.com>.
Yeah, I think so. Basic auth should work fine.
But in my test, it wouldn't...   I dont' know why.
(especially, in Zope & Apache Server...)

Actually, in IIS 5.0, every methods're ok.


----- Original Message ----- 
From: "Remy Maucherat" <re...@betaversion.org>
To: <sl...@jakarta.apache.org>
Sent: Wednesday, December 06, 2000 6:06 AM
Subject: Re: parseStatusLine? and Authorization?


> > In the case of 2),
> > If the WebDAV Client has "HTTP/1.1 401 Autorized Required" Response,
> > it is required to parse www-authenticate for realm and sendRequest
> > again
> > with "Authorization" Header like this:
> >     Authorization: Digest username="jericho",
> >                         realm="String $from_www-auathenticate",
> > nonce="...",
> >                         response="...", opaque="..."
> > -------------------------
> > so, the additional work is need for this part.....
> >          if (method.getStatusCode() == WebdavStatus.SC_UNAUTHORIZED) {
> >                 Header authenticateChallenge =
> >                     (Header) responseHeaders.get("www-authenticate");
> >                 if (authenticateChallenge != null) {
> >                     state.setAuthenticateToken
> >                         (authenticateChallenge.getValue());
> >                 }
> > for username, realm, nonce... etc...
> 
> I know about the status text problem. I had higher priority problems, so I
> didn't try to fix it yet.
> 
> Digest is not supported yet. Since it's a very important auth method for WebDAV,
> it's high on the priority list. Basic auth is supported (and it should work
> fine).
> 
> Remy
> 

Re: parseStatusLine? and Authorization?

Posted by Remy Maucherat <re...@betaversion.org>.
> In the case of 2),
> If the WebDAV Client has "HTTP/1.1 401 Autorized Required" Response,
> it is required to parse www-authenticate for realm and sendRequest
> again
> with "Authorization" Header like this:
>     Authorization: Digest username="jericho",
>                         realm="String $from_www-auathenticate",
> nonce="...",
>                         response="...", opaque="..."
> -------------------------
> so, the additional work is need for this part.....
>          if (method.getStatusCode() == WebdavStatus.SC_UNAUTHORIZED) {
>                 Header authenticateChallenge =
>                     (Header) responseHeaders.get("www-authenticate");
>                 if (authenticateChallenge != null) {
>                     state.setAuthenticateToken
>                         (authenticateChallenge.getValue());
>                 }
> for username, realm, nonce... etc...

I know about the status text problem. I had higher priority problems, so I
didn't try to fix it yet.

Digest is not supported yet. Since it's a very important auth method for WebDAV,
it's high on the priority list. Basic auth is supported (and it should work
fine).

Remy

Authorization: Basic?

Posted by "Park, Sung-Gu" <je...@thinkfree.com>.
Well.... I don't know why....   "Authorization: Basic....." is not working...
the debugging message is correct!!

    EBUG:WebdavClient:Authorization: Basic ajJyaWNobzpqMnJpY2hv
    DEBUG:WebdavClient:Response: HTTP/1.1 400 Bad Request

Nonethless, I've got "400 Bad Request" Response for COPY method in Apache mod_dav Server.
Why?  Any ideas?

  ----- Original Message ----- 
  From: Park, Sung-Gu 
  To: slide-dev@jakarta.apache.org 
  Sent: Wednesday, December 06, 2000 5:16 AM
  Subject: Re: parseStatusLine? and Authorization?


  In the case of 2),
  If the WebDAV Client has "HTTP/1.1 401 Autorized Required" Response,
  it is required to parse www-authenticate for realm and sendRequest again
  with "Authorization" Header like this:
      Authorization: Digest username="jericho",
                          realm="String $from_www-auathenticate", nonce="...",
                          response="...", opaque="..."
  -------------------------
  so, the additional work is need for this part.....
           if (method.getStatusCode() == WebdavStatus.SC_UNAUTHORIZED) {
                  Header authenticateChallenge =
                      (Header) responseHeaders.get("www-authenticate");
                  if (authenticateChallenge != null) {
                      state.setAuthenticateToken
                          (authenticateChallenge.getValue());
                  }
  for username, realm, nonce... etc...


  ----- Original Message ----- 
  From: "Park, Sung-Gu" <je...@thinkfree.com>
  To: <sl...@jakarta.apache.org>
  Sent: Wednesday, December 06, 2000 4:09 AM
  Subject: parseStatusLine? and Authorization?


  > 
  > 1)
  > For status-line tokenizing, it's used StringTokenizer as default Constructor.
  > But It's wrong.  the third parameter of the StatusLine is allowed to use a space.
  > The quick pactch for this is below:
  > 
  >        statusText = statusLine.substring(13);
  >         /*
  >         try {
  >             file://statusText = st.nextToken();
  >         } catch (NoSuchElementException ignored) {
  >         }
  >         */
  > 
  > 
  > 2)
  > I have a suggestion. 
  > For interoperability,  Authorization Header is required for COPY, MOVE, UNLOCK, etc...
  > How will it be going with this?   I think It's important...  even though TC4 is not supported.
  > 
  > 

Re: parseStatusLine? and Authorization?

Posted by "Park, Sung-Gu" <je...@thinkfree.com>.
In the case of 2),
If the WebDAV Client has "HTTP/1.1 401 Autorized Required" Response,
it is required to parse www-authenticate for realm and sendRequest again
with "Authorization" Header like this:
    Authorization: Digest username="jericho",
                        realm="String $from_www-auathenticate", nonce="...",
                        response="...", opaque="..."
-------------------------
so, the additional work is need for this part.....
         if (method.getStatusCode() == WebdavStatus.SC_UNAUTHORIZED) {
                Header authenticateChallenge =
                    (Header) responseHeaders.get("www-authenticate");
                if (authenticateChallenge != null) {
                    state.setAuthenticateToken
                        (authenticateChallenge.getValue());
                }
for username, realm, nonce... etc...


----- Original Message ----- 
From: "Park, Sung-Gu" <je...@thinkfree.com>
To: <sl...@jakarta.apache.org>
Sent: Wednesday, December 06, 2000 4:09 AM
Subject: parseStatusLine? and Authorization?


> 
> 1)
> For status-line tokenizing, it's used StringTokenizer as default Constructor.
> But It's wrong.  the third parameter of the StatusLine is allowed to use a space.
> The quick pactch for this is below:
> 
>        statusText = statusLine.substring(13);
>         /*
>         try {
>             file://statusText = st.nextToken();
>         } catch (NoSuchElementException ignored) {
>         }
>         */
> 
> 
> 2)
> I have a suggestion. 
> For interoperability,  Authorization Header is required for COPY, MOVE, UNLOCK, etc...
> How will it be going with this?   I think It's important...  even though TC4 is not supported.
> 
>