On Mon, Sep 30, 2002 at 10:03:27PM +0100, Joe Orton wrote:
> On Mon, Sep 30, 2002 at 03:04:06PM -0500, Florin Iucha wrote:
> > On Mon, Sep 30, 2002 at 08:35:34PM +0100, Joe Orton wrote:
> > > I can't reproduce any problems using long passwords over basic auth with
> > > neon here - bear in mind that 'x'es in the neon debug output includes
> > > the "Basic " string and the base64 encoded text includes the username
> > > and a colon.
> >
> > I have created "testuser" with "longpasswordsarecool".
> >
> > $ cat | base64-encode
> > testuser:longpasswordsarecool
> > dGVzdHVzZXI6bG9uZ3Bhc3N3b3Jkc2FyZWNvb2wK
> > $ grep dGVzdHVzZXI6bG9u err_long
> > Authorization: Basic dGVzdHVzZXI6bG9uZ3Bhc3M=
> >
> > Correct: dGVzdHVzZXI6bG9uZ3Bhc3N3b3Jkc2FyZWNvb2wK
> > Neon : dGVzdHVzZXI6bG9uZ3Bhc3M=
>
> The password has been truncated to 8 characters, and I'm guessing this
> happens before it gets to neon. Google tells me that the Solaris
> getpass() implementation, which is used by APR, will do this.
>
> Can you try commenting out the
>
> #define HAVE_GETPASS 1
>
> line in apr/include/arch/unix/apr_private.h, or adding an
>
> #undef HAVE_GETPASS
>
> in an appropriate place in passwd/apr_getpass.c so that the replacement
> getpass() implementation is used in APR?
That fixed the problem. I have copied the apr devel mailing list hoping
somebody will make that change for Solaris for the next version.
Thank you,
florin
--
"If it's not broken, let's fix it till it is."
41A9 2BDE 8E11 F1C5 87A6 03EE 34B3 E075 3B90 DFE4
- application/pgp-signature attachment: stored
Received on Tue Oct 1 00:20:45 2002