[jitsi-dev] account properties import


#1

I've looked at how properties are stored for accounts and here are a few
observations, I'd appreciate any suggestion about how to implement this:

- jitsi-defaults.properties is good for things that are very static
(like setting TLS preferences), but people using web start or some other
custom deployment are more likely to create their account preferences
(user, password) dynamically

- consider Jitsi bundled with some other product, the user logs in to
the other product and the same username/password would be used to create
a SIP account just for that one session

- the account password needs to be encrypted the Jitsi way and using the
CredentialsStorageService seems like the correct way to encrypt

- ProvisioningServiceImpl.java already has logic that may be useful in
the processProperty method:
https://github.com/jitsi/jitsi/blob/master/src/net/java/sip/communicator/plugin/provisioning/ProvisioningServiceImpl.java#L817

A few possible solutions:

- add a public method to ProvisioningServiceImpl for passing in a set of
properties

- or create a service similar to ProvisioningServiceImpl

- the method would accept a Properties object constructed by the application

- for convenience, the method or class may automatically prefix the
names, e.g. if invoked with the argument
prefix="net.java.sip.communicator.impl.gui.accounts.acc1234"

and properties:
ACCOUNT_UID=Jabber\:daniel@pocock.pro
USER_ID=daniel@pocock.pro
...

it would automatically convert to full property names, convert
passwords, etc.

- for receiving properties from an application that runs outside the
OSGi container, there may be a singleton object (similar to ArgHandler)
and something like ArgDelegator:

https://github.com/jitsi/jitsi/blob/master/src/net/java/sip/communicator/util/launchutils/ArgDelegator.java

to cache any properties and deliver them to the service when it becomes
active in OSGi.

Does all of this make sense? Is there any other way to go about this
that may be more effective? Is there any existing API I should consider
instead?


#2

I've looked at how properties are stored for accounts and here are a few
observations, I'd appreciate any suggestion about how to implement this:

- jitsi-defaults.properties is good for things that are very static
(like setting TLS preferences), but people using web start or some other
custom deployment are more likely to create their account preferences
(user, password) dynamically

- consider Jitsi bundled with some other product, the user logs in to
the other product and the same username/password would be used to create
a SIP account just for that one session

- the account password needs to be encrypted the Jitsi way and using the
CredentialsStorageService seems like the correct way to encrypt

- ProvisioningServiceImpl.java already has logic that may be useful in
the processProperty method:
https://github.com/jitsi/jitsi/blob/master/src/net/java/sip/communicator/p
lug in/provisioning/ProvisioningServiceImpl.java#L817

A few possible solutions:

- add a public method to ProvisioningServiceImpl for passing in a set of
properties

- or create a service similar to ProvisioningServiceImpl

- the method would accept a Properties object constructed by the

application

- for convenience, the method or class may automatically prefix the
names, e.g. if invoked with the argument
prefix="net.java.sip.communicator.impl.gui.accounts.acc1234"

and properties:
ACCOUNT_UID=Jabber\:daniel@pocock.pro
USER_ID=daniel@pocock.pro
...

it would automatically convert to full property names, convert
passwords, etc.

- for receiving properties from an application that runs outside the
OSGi container, there may be a singleton object (similar to ArgHandler)
and something like ArgDelegator:

https://github.com/jitsi/jitsi/blob/master/src/net/java/sip/communicator/u
til /launchutils/ArgDelegator.java

to cache any properties and deliver them to the service when it becomes
active in OSGi.

Does all of this make sense? Is there any other way to go about this
that may be more effective? Is there any existing API I should consider
instead?

The easiest way is probably to create a custom provisioning plugin,
completely replacing the existing one. Almost all of the code in the
existing service deals with detecting system properties for a URL and
downloading the data from there. For your custom solution, special handling
like deleting existing values when ${null} comes as a value or setting
system properties are probably not even required. And processProperty turns
into something really simple then: settting a property with the only special
handling if it is a password.

Ingo

ยทยทยท

On 2014-07-24 23:28, Daniel Pocock wrote: