Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Joshua Cranmer Newsgroups: comp.lang.java.programmer Subject: Re: tools for programming applets Date: Sun, 22 May 2011 17:39:42 -0400 Organization: A noiseless patient Spider Lines: 60 Message-ID: References: <028d2009-98b7-43a3-b02d-83eaa89db79e@glegroupsg2000goo.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sun, 22 May 2011 21:39:42 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="bAymlyY9SkaJNa8Tz2rerw"; logging-data="15657"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18H7+7H1g5+5NNvgViRMxduOAgKYBjgqXU=" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 In-Reply-To: Cancel-Lock: sha1:gNOALOlafzKlUxYLaZQtBa5S/fc= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4422 On 5/22/2011 8:18 AM, horos22 wrote: > Josuha, While I am used to the spelling and/or pronunciation of my last name being butchered, this is the first time in quite a while that I've seen my first name incorrectly spelled ;-) > I understand that this is a security risk - if used in production > systems. But as a development tool, it's invaluable. From a security risk, how would you lock it down in the production system yet keep it available in development? By the time you start trying to come up with mechanisms to allow that, you're not saving yourself any effort compared to just making a new server or hosting another install in a similar environment. > Consider protocol development. When I develop a ssh client, or mysql > client, or iscsi client, I don't need to make a new server instance or > somehow have to duplicate the server environment. Applets aren't exactly like an SSH client. While I'm not exactly sure what your use-case it is, it seems to me that the applet is acting more like a smart client that does middleware business management-y stuff; a close analogue to this would be an intranet application. > Suppose you had 10 developers working on an applet. What are they > supposed to do? Duplicate the parent environment 10 separate times? When I worked on an intranet project, that is precisely what we did. Everything from the copy of code we ran to the LDAP and MySQL databases we authenticated against were created as separate copies for every developer. > What if the central environment changes? Do you then need to propogate > those changes to all 10 daughter environments? what if two people want > to merge changes or then test their changes our versus production > data? Do they need then to impact production by having their applet > hosted in the production world? Yes to your first question; no to your second. It is possible to directly copy the production values to the non-production stuff. > This makes no sense. I can't believe there isn't something out there > to do this. Unix has a permissions system and its invaluable - you > open up the permissions on things to do development, get stuff done, > and then close down the permissions when you ship. There's gotta be a > way to overcome the extreme development penalty inherent in cloning > environments here; elsewise I feel damn sorry for the java applet > developer.. From my perspective, when hosting a webservice (including applets), one key thing you need to be sure of is that you do not treat the development testbed as the production environment. What happens if you accidentally introduce a security leak for debugging purposes? The entire world would see it in the production, while the development version remains (theoretically) locked down within a corporate firewall. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth