[josm-dev] shocking - unsecure password sending!

[Karl Guggisberg]

> Ah, so you confess that the Apache http stack is not *necessary* ;-)
Yes, I confess, it isn't necessary in the sense that JOSM would stop working
without it. Whatever JOSM wants to do, it can be done without the Apache
http library. And, of course, there are other libraries around.

My line of though was that new features often asked for would *benefit* from
a http client library (they would be easier, faster to implement and easier
to maintain). These features include OAuth and proxy authentication. And my
assumption was that, although JOSM programmers could try to code whatever
piece of software they need for JOSM, it would wise to rely on prebuilt
libraries in order to get the features out. I confess, that this isn't a
revolutionary idea either.  

As stoeckr points out, I might be wrong regarding proxy authentication. So
far I thought we would *need* (in the sense that it couldn't be done
withouth) a 3d party library for Digest Authentication and NTLM. 

The few OAuth client libraries I came across (just researching the web, no
practival experience with them yet) relied on 3d party libraries, though,
and for OAuth support it would be wise to rely on a library. But again, the
better if somebody has an OAuth client library which has no dependencies to
other libraries at all. 

-- Karl 


-----Ursprüngliche Nachricht-----
Von: Frederik Ramm [mailto:frederik at remote.org] 
Gesendet: Mittwoch, 7. Oktober 2009 16:55
An: karl.guggisberg at guggis.ch
Cc: josm-dev at openstreetmap.org
Betreff: Re: [josm-dev] shocking - unsecure password sending!

Hi,

Karl Guggisberg wrote:
> Why reinvent the weel? 

Ah, so you confess that the Apache http stack is not *necessary* ;-)

>  Luickly there are smart people providing http client libraries which 
> would shield JOSM from the nasty details of proxy authentication, 
> libraries which are tested against a heterogeneous set of proxy 
> software "in the wild".

Maybe JOSM could be built in a way to take advantage of a separately
downloaded Apache HTTP client if one is there, and silently fall back to the
built-in default if not? That way we wouldn't have to force all those
libraries onto our users.

Or else we can have a "proxy auth" plugin that people load if they want
proxy authentication with all bells and whistles.

That's one big gripe I have with the Java world. Instead of installing
libraries in a global location on a system, every smallest Java program
brings its own set of libraries because of course they all use a slightly
different version of each.

Bye
Frederik