Re: sfCodeBase from a password protected http site

Steve Loughran wrote:

> Goldsack, Patrick wrote:
>
>> Sanjay,
>>
>> Password-based authentication is not currently supported, we would need
>> to add this capability.
>> However, this alone would not be particularly secure since the
>> passwords, etc, would be sent in clear. It would not also not, as you
>> point out, protect the jar file from being read (though it would be
>> protected from tampering so long as the security was switched on and the
>> jar file signed). You would need an ssl session to protect the
>> visibility of the jar file and passwords. So if the jar file contains
>> passwords etc. held in clear - you would need to do this, or use some
>> other secured mechanism to download the file locally then use a file://
>> url.
>>
>> Patrick
>>
>
> I note that the SOAP-based CDL deployment API, which I am trying to 
> get working for may, does offer
>
> -upload of JAR files to the far end; you get back a URL that you can 
> then feed in to other descriptors
> -long haul connectivity over port 80
>
> Sanjay,
> it sounds like long-haul upload and deployment is what you are trying 
> to do. Is this right? I do not have anything I consider usable yet, 
> but should by the summer have a way of doing remote deployments using 
> SOAP.
>
> -steve

If it is ONLY remote deployment you require, then adding deployment 
proxy components to have long-haul deployment is fairly easy in 
SmartFrog.  Also,  the SmartFrog deployer model makes it easy to make 
the proxies relatively transparent to the end user.  Any transport could 
be layered under this - including SOAP if necessary.

The idea would be to write a deployer called, for example,  
RemoteDeployer which uses an attribute sfRemoteSite to determine on 
which node its partner remote proxy resides (and another to deterine the 
port if necessary - sfRemoteSitePort). Then by setting the deployer for 
a remote component to the right deployer, and setting the sfRemoteSite 
attibute, the component would be remotely deployed. We have done this 
kind of gateway component in other contexts. It would only be for whole 
new rooted deployments, and not for deploying children otherwise you 
would have to also do some work on liveness maintenance across the 
remote link.

One could even make it more transparent by defining  a new deployer that 
works as the current default one does, but would look at the 
sfProcessHost attriute to decide if a remote proxy needed using. For 
example - if in the same subnet - no proxy, if in a different subnet 
hand off to the proxy to contact the remote host and arrange the 
deployment. If a proxy were run on every host, this would give complete 
transparency for deployment. (But not for LAZY resolution, parent-child 
relathionships or other RMI calls.)

Patrick


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642