[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[buckminster-dev] Re: settings working proposal
|
I started a wiki page to capture points of our discussion so they don't
get lost in the comments -
http://wiki.eclipse.org/Settings_%28Buckminster%29
Other comments below...
Thomas Hallgren wrote:
Robert Dale wrote:
Another configuration aspect is that one might want specific settings
when running a particular Buckminster action. Picture an action that
builds an update site and then publishes it on an FTP server. In order
to build there is a need to access a keystore (for jar signing). In
order to publish, credentials on the ftp server are needed. For this it
might be more suitable with a "build configuration", explicitly
appointed when the command is executed, then a general purpose
configuration file.
Do we need three places, the preference store, a general configuration
file, and a build configuration to store settings?
>
> Perhaps it would be enough if all commands could appoint a specific
> configuration file? Then again, the concept of a default configuration
> file is appealing. I don't think it should be specific to headless
> though, it should be applied when doing things from the GUI as well.
I think maven has thought a lot about some of these problems and it
would be a good idea to see what they've done.
http://maven.apache.org/pom.html
http://maven.apache.org/settings.html
What I like: Preferences can be globally defined as well as defined
within a 'profile'. These profiles can be turned on and off by other
preferences and/or on the command-line.
Publishing to the FTP server is covered by <pom:distributionManagement>
and <settings:servers>. I'm thinking that maybe all URL things could be
managed in one place whether it's retrieving, publishing, or accessing
in some way. For instance,
<resource name="MySubversion">
<type>url</type>
<uri>https://my.subversion.server/repos/</uri>
<username>foo</username>
<password>bar</password>
</resource>
<resource name="MyFtp">
<type>url</type>
<uri>ftp://my.website.com</uri>
<username>foo</username>
<password>bar</password>
</resource>
<resource name="MyKeystore">
<type>keystore</type>
<uri>file://my.keystore</uri>
<storetype>jks</storetype>
<storepass>bar</storepass>
<resource>
And maybe these are passed down to actions through properties
<signjar storepass="${buckminster.resource.MyKeystore.storepass}"
keystore="${buckminster.resource.MyKeystore.uri}"/>
I also imagine that any of these configuration options could be
overridden or expanded by a configuration file specified on the
command-line: buckminster -c myconfig.xml
So now one potential issue becomes apparent: I have two configuration
files in two different places. In my particular use case I primarily
will use buckminster headless in continuous integration. Those
settings, atleast the credentials piece, will be very different than
what I store on my developer box. In any case, I think if a button
were added to the GUI to generate a headless.xml that most problems
would be taken care of. It would be a nice template to start out with
anyway.
The problem that I see with this approach is that there is a vast amount
of preferences and other settings that needs to be mirrored. Compiler
settings, target platform, Execution environment, etc. The keyring stuff
is just a small part of it.
I hesitated to suggest that all buckminster settings exist outside of
eclipse. See more below.
I don't know how eclipse headless works now WRT cvs, svn, etc tools
and credentials. What I am thinking is that buckminster would pass
them the credential information they need to access a resource instead
of configuring each tool individually. This would of course be optional.
Each tool provide their own configuration with GUI and all allowing you
to specify repositories and credentials for each. It would be a fairly
large undertaking if we were to take care of all of this for them.
Especially since both they and the Eclipse platform change over time.
I was hoping that the APIs already had the ability to pass this
information. Subversion does, but I couldn't find a way to do this with
CVS. So what I'm wondering here is how does one configure the cvs
user/pass for eclipse headless?
The main reason for wanting to do this is to avoid duplication.
In headless mode, I mentioned interactivity. What this means is
[...]
captured to the wiki
I have been unable to locate any useful information on the keyring
capabilities and API. If anyone has any pointers, I would greatly
appreciate it.
I sent a mail to the platform-core-dev@xxxxxxxxxxx mailing list asking
about this.
I'm attaching below this question/response for future reference...
If possible, I'd like to always use the keyring and other
capabilities that Eclipse provides.
And I thought the same thing which is why I suggested keeping the GUI
stuff to use eclipsabilities. I'm not sure what else outside of the
keyring can be used if we are to have our own xml file outside of the
workspace. More investigation into the keyring is needed to see what we
can really do with it.
I think one thing I need is clarification on the scope of using
credentials. This all started out with needing a way to store user/pass
for accessing a cquery and rmap. I probably got carried away and
extended that scope. I think we should keep it simple.
http://dev.eclipse.org/mhonarc/lists/platform-core-dev/msg01039.html
------------------------------------------------------------------
Hi,
We are trying to figure out the best way to access URL's that require
authentication from a headless execution environment. The environment
has access to the eclipse resource framework but not to any of the UI
components.
My question is, what capabilities can we reuse so that we avoid storing
names and passwords in multiple places? Can we use the Eclipse keyring
from headless mode? How is it accessed? Where do we find the API's?
Kind Regards,
Thomas Hallgren
--------------------------------------------------------------------
Thomas,
I do not believe Eclipse provides such a mechanism, but I am 99.9% sure it
is technically feasible... if you create your own plugin
If I remember, the authentication is managed by an Authenticator
Authenticator.setDefault (new MyAuthenticator ());
If we manage to register a headless authenticator first, we should be able
to do what we want (meaning we have to code it...)
Check UpdateManagerAuthenticator for a sample
We may need to create our own bundle, that is executed first before any
update code is executed ?
Now, how do we access the keyring...
The code may have changed, but I used to access the Keystore of the
JVM...There may be some code around to show you
Check org.eclipse.update.internal.security.JarVerifier
So in a nutchell, create your osgi bundle, madify the ini to load your
bundle first, in the start register your authenticator, and from there code
how you want to retrieve the uid/passwd
Does it help (somehow?)
Christophe Elek - Senior Software Analyst
IBM Rational Serviceability Architect
IBM Toronto Lab 8200 Warden Avenue, Markham, Ontario, L6G 1C7
Phone Number: (905) 413-3467
Email: celek@xxxxxxxxxx
-----------------------------------------------------------------------
Thomas,
The Platform/Core component does provide a means of caching usernames
and paswords in a keyring file (see Platform#addAuthenticationInfo). The
UI/Net plug-in provides a URL authenticator in the manner that
Christophe described (i.e. I don;t know if Christophe is aware that the
code he mentions has been moved to UI/Net). If you want to perform
headless authentication, you would need to provide your own
Authenticator and you could write it to cache that username and password
in the keyring. However, there are a couple of things to be aware of:
1) The keyring is not a secure store unless Eclipse is started with the
-password command line option (hence the warning on the CVS
authentication dialog). In the future, Eclipse will probably move to JAAS.
2) I could not find a description of when Java calls back to the
authenticator but it appears that Java calls the authenticator to obtain
a username and password and will not call the authenticator again unless
authentication fails. You would need to write your authenticator in such
a way that it only returns the cached credentials the first time it was
called and prompts on subsequent calls (or fails if prompting was not
possible). The Net/UI plug-in does not cache passwords in the keyring
because of these complications.
3) In case of failure, you would need to provide some way for your users
to change the cached credentials.
Hope this helps,
Michael
----------------------------------------------------------------------
