Oh, Forgot to add. Bear in mind that Facebook SSO uses Activity.startActivityForResult(..) which gives them access to Activity.getCallingActivity() once authentication Activity is spawned.
-- H On Dec 17, 2011, at 5:22 PM, Harri Smått wrote: > Hi, > > AFAIK there is no way to determine calling application from your Service > automatically (as many have stated already). As for Facebook SSO, it's a bit > different situation since it handles logging in directly into their web > services via assigned access token. In your situation you ought to do > something similar though, especially give your clients a client library for > making it easier to authenticate with your Android Service. > > Now, if you have a web service, which clarifies your situation a lot, the > whole authentication procedure could go roughly as follows. > > 1. Your clients have to register their package signature vie web interface to > server side. > 2. Client calls, e.g, identify(signature) IPC method after binding. > 3. Service forwards it to web service, which determines is it ok to continue. > 4. Service assigns client a session id on positive answer. > > It would be totally up to you do you want to do whole identifying procedure > as a separate thread, which returns session id via Service callback > mechanism, or as a blocking method which returns it instantly. When it comes > to safely dealing with client signature, and package signatures in general, > goes beyond my knowledge though. > > -- > H > > On Dec 17, 2011, at 1:14 AM, Bsweet wrote: > >> Ultimately what I would like to do is check the signature of the bound >> application. >> >> I want to have a mechanism where developers can register their >> signatures with my service, then I will check to see if their package/ >> signature combination matches what I have in my web service. >> >> This is exactly what the Facebook Android application does for Single >> Sign On. >> >> I just can't find a clean way to get the calling application. >> >> >> On Dec 16, 8:46 am, Harri Smått <[email protected]> wrote: >>> Hi, >>> >>> I would go for a simple handshaking mechanism quite likely. You can let >>> anyone bind to yourservicebut disallow usage of IPC methods for >>> unidentified clients. E.g. >>> >>> 1. Client connects toservice. >>> 2. After connection is established, client is required to call, say, >>> identify() IPC method which returns a String, Integer, what so ever. >>> 3. After receiving this challenge, client has to call identify(result) >>> method which gives client a session id. >>> 4. For all of the later calls client has to use this session id among with >>> the call. >>> >>> Quite obviously all this depends totally on how much security you're >>> required to have within your client-serviceinteraction but some very simple >>> handshaking protocol might work surprisingly well if it's kept secret. >>> >>> -- >>> H >>> >>> On Dec 16, 2011, at 6:26 PM, Bsweet wrote: >>> >>> >>> >>> >>> >>> >>> >>>> It is the spoof part that concerns me. >>> >>>> Anyone else out there have any creative ideas? >>> >>>> Right now I'm considering just checking who is on the top of the >>>> activity stack, but that is hokey and not reliable. >>> >>>> On Dec 16, 4:30 am, Mark Murphy <[email protected]> wrote: >>>>> On Thu, Dec 15, 2011 at 9:54 PM, Kristopher Micinski >>> >>>>> <[email protected]> wrote: >>>>>> When you get a bind in yourservice(your onBind) can you just take >>>>>> the intent and get component associated with it? >>> >>>>>> From Intent: >>>>>> ComponentName getComponent() >>>>>> Retrieve the concrete component associated with the intent. >>> >>>>> That should be the recipient, not the sender. >>> >>>>> The only way I know to find out whoboundto you is if you require >>>>> that information in an extra, and that can always be spoofed. The >>>>> expectation is that you should not care *who*boundto you, merely >>>>> whether they had sufficient permissions to do so. >>> >>>>> -- >>>>> Mark Murphy (a Commons >>>>> Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy >>> >>>>> _Android Programming Tutorials_ Version 4.1 Available! >>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Android Developers" group. >>>> To post to this group, send email to [email protected] >>>> To unsubscribe from this group, send email to >>>> [email protected] >>>> For more options, visit this group at >>>> http://groups.google.com/group/android-developers?hl=en >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Android Developers" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/android-developers?hl=en > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
