[dev] module for horde?

[Eric Rostetter]

Quoting Michael Häusler <michael@akatose.de>:

> Quoting Eric Rostetter <eric.rostetter@physics.utexas.edu>:
> 
> > 1) Does anyone think it would be good to add this kind of function to
> > horde?
> 
> I think this would be very useful, but I am obviously lacking in
> imagination, how thight the integration with Horde could be.

Not very :)  Basically, I made it appear in my Horde site, made it respect
themes for the inital page colors, made it respect Horde authentication,
made it configurable (proof of concept at least) via config/conf.php file,
etc.

> A php-generated applet.conf could provide persistent preferences to the
> applet. So I am curious: What (further) modifications did you make to jta?

I've only made it use config/conf.php, but obviously it would also work 
via preferences if we wanted to add those.

I don't touch the java source at all, only the html that calls it.  

> > 2) If so, are you interested in my version?  Or should we start with a
> > newer version of the jta and go from there?
> 
> Version 2.5 also supports Java WebStart, which works well for me. I am not
> sure, but perhaps we would only have to generate a corresponding .jnlp
> file for integration with horde.

I have no idea, as I use 2.0 only, and not WebStart.  One concern is how
hard, or easy, would it be to support with WebStart updates?  If it is in
CVS, and they have to update with our code, we at least know what is in the
code.  But if they update via WebStart, it could be a support issue...
 
> I would prefer just generating some wrapper for starting (either .jnlp or
> some applet-tag with autogenerated applet.conf). If we have to modify the
> jta sources, we cannot easily take advantage of bug-fixes and features in
> new versions of jta.

I definately do not, and do not want to, modify the java.  Only the html.
So updates really shouldn't be a problem.

> Of course, this is only based on my ignorance of the possible additional
> features, that source code modification of jta may provide.

Basically I don't touch "jta" per se.  It is the html that you need to wrap
around jta that I modify.

> > Third, the code as stated above will only allow you to connect back to
> > the web server (due to Java security -- the client can't connect to
> > anything except the server it downloaded the applet from).  So to allow
> > connecting to a different machine, you need to use a "ssh relay" daemon.
> 
> Another possibility of lifting security limitations is the usage of a
> signed applet / WebStart application. The example installation on the jta
> homepage ( http://javassh.org/ ) uses a selfsigned certificate and
> requests full rights on the client machine in its .jnlp-file.
> This is a question of individual preference (or degree of administration
> rights / possibilities on your server / isp): Do you want the client
> to "trust" you or do you want another daemon on your server?

This would take someone with more time/knowledge than me to do probably.

One problem is, I'm incredibly happy with jta 2.0, and see no need to change.
I know there are security issues (man in the middle, etc) but I'm willing
to deal with those, as long as I don't have clear text passwords...

I'm also willing to go forward to eliminate some security concerns, but
I simply don't know/care enough to start the initiative.   But I'd definately
support an initiative if started by someone else ;)

> Best regards
> Michael Häusler


-- 
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Why get even? Get odd!