Menu
▾
▴
geotools-devel
|
From: Richard G. <rg...@re...> - 2005-04-15 21:22:48
|
I have commented out some lines in WFSDataStore.getConnection() that
with Authentication:
// synchronized (Authenticator.class) {
// Authenticator.setDefault(auth);
// connection.connect();
// Authenticator.setDefault(null);
// }
The setting and unsetting of the default Authenticator destroys the
basic authentication system set up now in uDig. Ideally the security
manager in uDig will be configured properly to prevent this from
occuring, but that is future work. Everyone else needs to play nicely in
the meantime :)
I have left the rest of the authentication/user-pass bits untouched, as
they might be useful if a better solution arises. One idea I had was
that the datastore provides a mechanism that allows an authentication
object to inquire about any previously entered usernames/passwords.
Any other ideas are welcome!
Richard
|
|
From: Jody G. <jga...@re...> - 2005-04-15 21:40:43
|
Richard Gould wrote:
> I have commented out some lines in WFSDataStore.getConnection() that
> with Authentication:
>
> // synchronized (Authenticator.class) {
> // Authenticator.setDefault(auth);
> // connection.connect();
> // Authenticator.setDefault(null);
> // }
>
> The setting and unsetting of the default Authenticator destroys the
> basic authentication system set up now in uDig. Ideally the security
> manager in uDig will be configured properly to prevent this from
> occuring, but that is future work. Everyone else needs to play nicely
> in the meantime :)
>
> I have left the rest of the authentication/user-pass bits untouched,
> as they might be useful if a better solution arises. One idea I had
> was that the datastore provides a mechanism that allows an
> authentication object to inquire about any previously entered
> usernames/passwords.
>
> Any other ideas are welcome!
Geotools could make use of any of the Security authentication services
APIs. By making use of a an API (rather than username/password
DataStoreFactory.PARAMs as is done by WFS and most Database
implemetnation), applications like GeoServer and uDig would be able to
connect GeoTools up to the correct information.
This could also be provided by the new Hints? If people think that is a
good option?
Jody
|
|
From: Jody G. <jga...@re...> - 2005-04-15 21:48:00
|
On further reflection commenting out the existing code is probably not the best idea. Should check with the module maintainer first (and GeoServer second). Could we set it up so WFS only clobbers the existing Authenticator if and only if it has a username/password to supply? That way we can leave the geotools working, and by simply removing the username/password fields from our wizard prevent WFS from ever wrecking the application Authenticator. Quite the design that Authenticator... Jody |
|
From: Richard G. <rg...@re...> - 2005-04-15 23:12:22
|
Jody Garnett wrote: > On further reflection commenting out the existing code is probably not > the best idea. Should check with the module maintainer first (and > GeoServer second). > > Could we set it up so WFS only clobbers the existing Authenticator if > and only if it has a username/password to supply? > That way we can leave the geotools working, and by simply removing the > username/password fields from our wizard prevent WFS from > ever wrecking the application Authenticator. > > Quite the design that Authenticator... > Jody I have done this. Richard |
|
From: David Z. <dav...@gm...> - 2005-04-15 23:51:34
|
This really makes those two parameters useless. Richard, please put it back. When GT has a plan for validation in a generic way ... then I will be happy to look into this more. That said, this is a limitation in the Java API. I could see alternative approaches (like either passing in username/pass or an authenticator), but by now we have gotten rather complex for a single datastore (put these thoughts towards a generic solution?). I'll think on it a bit and see what I can come up with. David On 4/15/05, Richard Gould <rg...@re...> wrote: > Jody Garnett wrote: >=20 > > On further reflection commenting out the existing code is probably not > > the best idea. Should check with the module maintainer first (and > > GeoServer second). > > > > Could we set it up so WFS only clobbers the existing Authenticator if > > and only if it has a username/password to supply? > > That way we can leave the geotools working, and by simply removing the > > username/password fields from our wizard prevent WFS from > > ever wrecking the application Authenticator. > > > > Quite the design that Authenticator... > > Jody >=20 > I have done this. >=20 > Richard >=20 >=20 > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > |
|
From: <rg...@re...> - 2005-04-16 02:19:38
|
I wasn't clear enough in my last message - I should have been more specific. I implemented Jody's idea, thus everything should still work. Basically I did was enclose the Authenticator setting in an: if (username != null && password != null) if that is still a problem, let me know. Thanks Richard Quoting David Zwiers <dav...@gm...>: > This really makes those two parameters useless. Richard, please put it > back. When GT has a plan for validation in a generic way ... then I > will be happy to look into this more. > > That said, this is a limitation in the Java API. I could see > alternative approaches (like either passing in username/pass or an > authenticator), but by now we have gotten rather complex for a single > datastore (put these thoughts towards a generic solution?). > > I'll think on it a bit and see what I can come up with. > > David > > On 4/15/05, Richard Gould <rg...@re...> wrote: > > Jody Garnett wrote: > > > > > On further reflection commenting out the existing code is probably not > > > the best idea. Should check with the module maintainer first (and > > > GeoServer second). > > > > > > Could we set it up so WFS only clobbers the existing Authenticator if > > > and only if it has a username/password to supply? > > > That way we can leave the geotools working, and by simply removing the > > > username/password fields from our wizard prevent WFS from > > > ever wrecking the application Authenticator. > > > > > > Quite the design that Authenticator... > > > Jody > > > > I have done this. > > > > Richard > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _______________________________________________ > > Geotools-devel mailing list > > Geo...@li... > > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X