||unity-dev|| testing Unity's policy file server

Discussion list for Unity developers. unity-dev at moock.org
Sat Apr 12 21:46:51 CDT 2008


Hey Colin... I'm not sure how this could possibly help... I'm hesitant, but
I think even if with more time to consider the pros vs cons, I'd say, no?

thanks though.. I think my method is working ok :)

-Jayson

On Sat, Apr 12, 2008 at 5:13 PM, Discussion list for Unity developers. <
unity-dev at moock.org> wrote:

> hi jayson,
> if we allow you to specify a separate policy port and policy.xml file
> for each individual IP on a specific machine, will that solve your
> problem?
>
> e.g.,
> ip 1.1.1.1: port 843, file p1.xml
> ip 2.2.2.2: port 843, file p2.xml
> ip 3.3.3.3: port 9102, file p3.xml
>
> colin
>
> Discussion list for Unity developers. wrote:
> > ok here's my deal.. I've not seen the crash in a couple u2 instances on
> my
> > servers with this patch. However, I cannot use this patch, so I've
> rolled it
> > back.
> >
> > This is why:
> >
> > I have several servers with more than a few U2 instances on the same IP,
> but
> > listening for the clients on different ports. Now, the easiest thing is
> to
> > not specify a port other than 843 for the security check.. why? because
> then
> > I'd have to mess around with port hopping to choose one available for
> EACH
> > instance.. and then, the client would have to make an swf code change to
> > load the policy file from THAT port explicitly.. PITA!
> >
> > So.. I have expanded my custom solution of a standalone policy server
> for
> > EACH ip on 843, that serves up all the allowed domains and ports-to..
> it's
> > the only way I can think of making it work, and easier to manage. Mind
> you,
> > this would mean that people can see what domains use a particular
> port-set
> > on my servers... so "technically" a breach of privacy but not really a
> > security threat.
> >
> > Now a note to Gabriel -- are you SURE you placed the new jar in the
> correct
> > location?? the class not found error means to me that you either don't
> have
> > it in the right place, or, you have a path issue -- OR --- you perhaps
> have
> > a filename CASE issue? on unix, unity_optional.jar is NOT the same as
> > Unity_optional.jar, or unity_Optional.jar, etc... double check those..
> >
> > -Jayson
> >
> > On Fri, Apr 11, 2008 at 3:02 PM, Discussion list for Unity developers. <
> > unity-dev at moock.org> wrote:
> >
> >> yup, that's all definitely true. (except for the stupid adobe part. as
> >> much as it's annoying, security is critical for flash player's success.
> >> just recently, usatoday.com was subject to a redirect attack that
> >> exploited flash player's old security model. if flash player gets a
> >> reputation for being insecure, the platform will die quickly.)
> >>
> >> jayson, have you tried the patch approach yet? for testing purposes,
> >> we'd like to get as many installations as possible with the patch
> >> approach while we work on the real fix.
> >>
> >> colin
> >>
> >>
> >> Discussion list for Unity developers. wrote:
> >>> fwiw, I took an old copy of Unity1 and simply modified the room
> >> dispatcher
> >>> to wait for the policy request, and then to send out the policy from a
> >> file
> >>> system file. ..this is working for me and a few clients right now
> >> without
> >>> issue.. the downside is that it's a second "application" to manage,
> and
> >> uses
> >>> up more resources than should be necessary.. but it works.. no restart
> >> of
> >>> the primary service or changes otherwise
> >>>
> >>> this could be done by any simple server created with any language
> >> running
> >>> along side U2 -- in java, vb or whatever.. it literally just has to
> >> accept
> >>> connections on port 843 (or whatever you want), and wait for the
> >> request,
> >>> and then send out the policy data and terminate the connection. In my
> >> case,
> >>> 843 worked easily enough with no code changes anywhere else
> whatsoever.
> >>>
> >>> stupid adobe.
> >>>
> >>>
> >>>
> >>> -Jayson
> >>>
> >>> On Fri, Apr 11, 2008 at 8:30 AM, Discussion list for Unity developers.
> <
> >>> unity-dev at moock.org> wrote:
> >>>
> >>>> HI all and thanks for all your replies and sorry for being so
> >> stressed...
> >>>> so here is the result of testing with realterm:
> >>>>
> >>>> each time i'm clicking on "open" button with mydomain.com:843, unity
> >>>> log.txt
> >>>> write the following:
> >>>>
> >>>>
> >>>> Exception in thread "Thread-5" java.lang.NoClassDefFoundError:
> >>>> org/moock/unity/core/ClientBufferedReader
> >>>>        at
> >>>>
> >>>>
> >>
> org.moock.unity.opt.policyserver.PolicyServer$Client.<init>(PolicyServer.java:122)
> >>>>        at
> >>>>
> org.moock.unity.opt.policyserver.PolicyServer.run(PolicyServer.java:85)
> >>>>        at java.lang.Thread.run(Unknown Source)
> >>>>
> >>>> i have 2.0.2 release running for theses tests...
> >>>>
> >>>> Regards
> >>>>
> >>>> Gabriel
> >>>>
> >>>> ----- Original Message -----
> >>>> From: "Discussion list for Unity developers." <unity-dev at moock.org>
> >>>> To: <unity-dev at moock.org>
> >>>> Sent: Friday, April 11, 2008 8:17 AM
> >>>> Subject: ||unity-dev|| testing Unity's policy file server
> >>>>
> >>>>
> >>>>> a quick note for those troubleshooting unity's policy file server.
> >>>>>
> >>>>> To test whether the Policy File Server is running properly on the
> >>>>> intended port, use a terminal to telnet to the port, then send the
> >>>>> string "<policy-file-request/>" followed by a null byte (ASCII 0).
> On
> >>>>> Windows, the free software RealTerm (http://realterm.sourceforge.net
> )
> >>>>> can be used to connect and send the required message.
> >>>>>
> >>>>> Steps for testing with RealTerm:
> >>>>> 1) on the Display tab, check "Half Duplex"
> >>>>> 2) on the Port tab, in the port pulldown, enter your domain and port
> >> in
> >>>>> the following format:
> >>>>>
> >>>>> yourdomain.com:nnn
> >>>>>
> >>>>> (where nnn is your port)
> >>>>> 3) Click "Open"
> >>>>> 4) on the Send tab, in the first pulldown menu to the left of "Send
> >>>>> Numbers", enter <policy-file-request/>
> >>>>> 5) click Send ASCII
> >>>>> 6) click the "0" button
> >>>>>
> >>>>> if the policy file server is working properly, you should see the
> >>>>> contents of your policy.xml file appear in the terminal window.
> >>>>>
> >>>>> colin
> >>>>>
> >>>>> --
> >>>>> you're a unity-dev subscriber. to unsubscribe, visit
> >>>>> www.moock.org/mailman/listinfo/unity-dev/
> >>>>>
> >>>>> superb hosting for this list and moock.org is generously provided by
> >>>>> Rackspace. See: http://www.rackspace.com/?supbid=moock
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> you're a unity-dev subscriber. to unsubscribe, visit
> >>>> www.moock.org/mailman/listinfo/unity-dev/
> >>>>
> >>>> superb hosting for this list and moock.org is generously provided by
> >>>> Rackspace. See: http://www.rackspace.com/?supbid=moock
> >>>>
> >>> --
> >>> you're a unity-dev subscriber. to unsubscribe, visit
> >> www.moock.org/mailman/listinfo/unity-dev/
> >>> superb hosting for this list and moock.org is generously provided by
> >> Rackspace. See: http://www.rackspace.com/?supbid=moock
> >> --
> >> you're a unity-dev subscriber. to unsubscribe, visit
> >> www.moock.org/mailman/listinfo/unity-dev/
> >>
> >> superb hosting for this list and moock.org is generously provided by
> >> Rackspace. See: http://www.rackspace.com/?supbid=moock
> >>
> > --
> > you're a unity-dev subscriber. to unsubscribe, visit
> www.moock.org/mailman/listinfo/unity-dev/
> >
> > superb hosting for this list and moock.org is generously provided by
> Rackspace. See: http://www.rackspace.com/?supbid=moock
> --
> you're a unity-dev subscriber. to unsubscribe, visit
> www.moock.org/mailman/listinfo/unity-dev/
>
> superb hosting for this list and moock.org is generously provided by
> Rackspace. See: http://www.rackspace.com/?supbid=moock
>


More information about the unity-dev mailing list