I was going to create a HostAuthenticationToken interface to replace the InetAuthenticationToken with methods:
getHostname() : String getHostAddress() : String The implementations would mirror the ServletRequest's getRemoteHost() and getRemoteAddr() methods respectively (but could be used outside of a Servlet environment of course). For XMPP, if this doesn't make sense, you could always just create a custom UsernamePasswordToken subclass that implements an XmppAuthenticationToken interface that returns the JID or whatever else you may need. Let me know if anyone has any objections or further ideas. Regards, Les On Fri, Dec 18, 2009 at 9:00 AM, Jason <[email protected]> wrote: > cool - this will also mean I can use an XMPP jid instead of an inetAddress > here which would be very handy. > > Les Hazlewood wrote: >> >> We didn't receive any objections to this change, so I've created an >> issue to track it: >> >> https://issues.apache.org/jira/browse/SHIRO-121 >> >> Regards, >> >> Les >> >> On Thu, Dec 17, 2009 at 3:28 PM, Tauren Mills <[email protected]> wrote: >>> >>> I would love to have GAE compatibility and won't cry over the loss, I say >>> go >>> for it! >>> >>> Tauren >>> >>> >>> On Fri, Dec 11, 2009 at 10:03 AM, Jeremy Haile <[email protected]> wrote: >>> >>>> I love that idea! Using InetAddress is mostly just an annoyance I >>>> think! >>>> >>>> >>>> >>>> Les Hazlewood wrote: >>>> >>>>> I was thinking about Google App Engine and then I remembered this >>>>> thread and wanted to bump it up for discussion. >>>>> >>>>> What does everyone think about changing all references from >>>>> InetAddress to a String? There are 181 places in code this is >>>>> referenced, so its not a trivial change (but not difficult), and >>>>> would break some backwards-compatibility, but it would make us GAE >>>>> compatible (as far as I can tell, this is the only think in the way of >>>>> being GAE compatible). >>>>> >>>>> It is interesting that the ServletRequest API does not use the >>>>> InetAddress class either, but also just uses Strings. >>>>> >>>>> Thoughts? >>>>> >>>>> - Les >>>>> >>>>> On Mon, Nov 23, 2009 at 10:14 AM, Kalle Korhonen >>>>> <[email protected]> wrote: >>>>> >>>>> >>>>>> Restricted - as in it's not in the the whitelist >>>>>> (http://code.google.com/appengine/docs/java/jrewhitelist.html). There >>>>>> are only certain classes that are allowed to be loaded. We could make >>>>>> using InetAddress optional. But Google is known to make changes to the >>>>>> whitelist, allowing more classes upon request. >>>>>> >>>>>> Kalle >>>>>> >>>>>> >>>>>> On Mon, Nov 23, 2009 at 6:47 AM, Les Hazlewood<[email protected]> >>>>>> wrote: >>>>>> >>>>>> >>>>>>> Restricted in what way? Not instantiated? Or the class is not even >>>>>>> allowed to be loaded by the classloader? >>>>>>> >>>>>>> Do you have a stack trace you could send along? >>>>>>> >>>>>>> The InetAddress is not strictly mandatory - it is there as a security >>>>>>> feature to retain the IP from where the end-user initiates their >>>>>>> application interaction so it is available easily to the application, >>>>>>> something valuable to many apps. Something might be able to be done >>>>>>> to make this work in App Engine easily, but I'm not sure what without >>>>>>> knowledge of what is going wrong. Please also feel free to share any >>>>>>> links to resources about how to deal with these restrictions if you >>>>>>> have them. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Les >>>>>>> >>>>>>> On Sun, Nov 22, 2009 at 11:44 PM, rwilson<[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>>> Has anyone successfully integrated shiro with google app engine. >>>>>>>> java.net.InetAddress is a restricted class. >>>>>>>> Any suggestions? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Roy >>>>>>>> -- >>>>>>>> View this message in context: >>>>>>>> http://n2.nabble.com/google-app-engine-tp4049065p4049065.html >>>>>>>> Sent from the Shiro User mailing list archive at Nabble.com. >>>>>>>> >>>>>>>> >>>>>>>> >> >
