I'm trying to make a Buzz viewer for Japanese mobile (not so smart) phones, which cannot execute Javascripts.
And I'm in trouble to navigate OAuth process.
To get authorization, first, you need to go
https://www.google.com/buzz/api/auth/OAuthAuthorizeToken
with parameters below (as documented in OAuth API/Buzz API docs).
oauth_token
domain
scope
iconUrl(optional)
hd(optional)
hl(optional)
btmpl(optional)
Expecting rather simple templete, I've set btmpl parameter as 'mobile'.
But it still includes Javascript-assisited-buttons.
Thus, most of the Japanese mobile phones (and its browser) cannot
click "OK, continue" button. Nor OAuth work.
Is there any solution to show simpler template?
At first, I planned to post above to Google Buzz API Developer forum.
But I've changed my mind. This is common problem in all Google's OAuth processes.
Where/Who can I ask for?
Tuesday, June 15, 2010
Tuesday, June 1, 2010
micro(nano?) Auth
just thinking now... not yet completed memo.
For mobile (or whatever computers which run modern OS) device, every "Native-application" call for kernel would better be under MAC(Mandatory Access Control).
In this case, request-token can be used.
Request tokens are issued by OS while the application is certified. The token is checked for Revokation. MAC on each kernel call realizes "real-time Revokation".
Of course, periodical check would be available, and with less load; such a s "on app booting only" or "on OS rebooting only" type.
I'd better make a survey on SELinux case...
For virtualization Hypervisors, MAC can be useful, because application ACL is almost compatible for various guest OS.
But it should not degrade performance drastically.
Anyway, every kernel call is trapped by Hypervisor (CPU may help passing thru for most of the cases). And there, MAC can be done.
How to check?
Full Certification is heavy process. Just check matching of fingerprint? Or, just booting/loaded to memory as DLL case? I guess short-handed check shall be done on each load of executable objects.
But, "on writable-memory exec" would be the path to jail-breaking of executable loading check although some CPU architectures inhibit such operation(Stack area corruption and jump to anywhere hacker'd like is the very familier opration.)
For mobile (or whatever computers which run modern OS) device, every "Native-application" call for kernel would better be under MAC(Mandatory Access Control).
In this case, request-token can be used.
Request tokens are issued by OS while the application is certified. The token is checked for Revokation. MAC on each kernel call realizes "real-time Revokation".
Of course, periodical check would be available, and with less load; such a s "on app booting only" or "on OS rebooting only" type.
I'd better make a survey on SELinux case...
For virtualization Hypervisors, MAC can be useful, because application ACL is almost compatible for various guest OS.
But it should not degrade performance drastically.
Anyway, every kernel call is trapped by Hypervisor (CPU may help passing thru for most of the cases). And there, MAC can be done.
How to check?
Full Certification is heavy process. Just check matching of fingerprint? Or, just booting/loaded to memory as DLL case? I guess short-handed check shall be done on each load of executable objects.
But, "on writable-memory exec" would be the path to jail-breaking of executable loading check although some CPU architectures inhibit such operation(Stack area corruption and jump to anywhere hacker'd like is the very familier opration.)
Subscribe to:
Posts (Atom)