Hi Paul, The concern regarding 3rd party native .so as authenticator plugins is mainly related to Tizen Privileges. (Pt. 1 of my mail). Tizen App Controls are widely used in Tizen Native (Mobile profile), which is some sort of extension you may say. But it is not yet finalized whether to use App Controls as SSO plugins, so if you would like to share your suggestions please feel free :)
- Thanks and Regards, Manasij Samsung R&D Institute India, Bangalore manasij.r AT samsung.com ------- Original Message ------- Sender : Hanchett, Paul<[email protected]> Date : Feb 20, 2014 21:16 (GMT+05:30) Title : Re: [Dev] Inclusion of glib headers in Tizen Native public header files If I may say, EXE is a *reallly* bad choice of extension name because it has too many overloaded meanings from that /other/ OS... Paul Paul Hanchett ------------------- Infotainment Engineer MSX on behalf of Jaguar Land Rover One World Trade Center, 121 Southwest Salmon Street, 11th Floor, Portland, Oregon, 97204 Email: [email protected] ------------------- Business Details: Jaguar Land Rover Limited Registered Office: Abbey Road, Whitley, Coventry CV3 4LF Registered in England No: 1672070 On Thu, Feb 20, 2014 at 12:19 AM, MANASIJ SUR ROY <[email protected]> wrote: Hi Alex, Thanks for sharing the multiplugin code. >From the code I can see that "--list-plugin" and "--load-plugin" options have >been added for plugin loader daemons. So I think plugin loaders can decide the >type of the plugin file? (i.e. to use .so or .exe) The reason we are evaluating .exe as authenticator plugins are: 1) Tizen mandates the API level access control for security sensitive operations(Privileges). For .so, it is the responsibility of the loading application/process to have the privileges required by the .so. In our case it will be plugind, which can not know the list of privileges required by the authenticator plugins beforehand. 2) Tizen::Social namespace has "Account" module which lets 3rd party developers to create app controls (.exe) for doing CRUD on Tizen accounts. We can integrate SSO functionalities with these app controls so that they dont need to deploy one .exe (for Tizen::Social Account) and one .so (for SSO). So we would like to know, from gSSO's point of view is there any issue if plugins are .exe instead of .so? - Thanks and Regards, Manasij Samsung R&D Institute India, Bangalore ------- Original Message ------- Sender : Alexander Kanavin<[email protected]> Date : Feb 17, 2014 22:57 (GMT+05:30) Title : Re: [Dev] Inclusion of glib headers in Tizen Native public header files Hello Manasij, the multiple plugin loader support in gsso has been completed and published here in the multiplugin branch of gsso: http://code.google.com/p/accounts-sso/source/list?repo=gsignond&name=multiplugin We still need to review the code, merge it into the master branch, update the online documentation and release the new version into Tizen repositories, but you can check out the code from git and play with it already now on your local machine. The topmost commit adds the documentation about how it works :) Let us know if there are any issues etc. Regards, Alex On 01/31/2014 02:35 PM, MANASIJ SUR ROY wrote: > Hi Jussi, Alex, > > With the approach you mentioned, I am able to create a sample Tizen Plugin > Loader and able to communicate with both gsignond and Tizen plugins. > I will keep watching /profile/ivi/gsignond and accounts-sso google code repo > for the official release and docs regarding the support of multiple plugind's. > > Thank you for the help. > > - Manasij > Samsung R&D Institute India, Bangalore > manasij.r AT samsung.com > > ------- Original Message ------- > Sender : Alexander Kanavin<[email protected]> > Date : Jan 15, 2014 19:45 (GMT+05:30) > Title : Re: [Dev] Inclusion of glib headers in Tizen Native public header > files > > On 01/15/2014 01:26 PM, Kanavin, Alexander wrote: > >> You would have to provide a Tizen specific >> plugin loader, the job of which is to translate the Tizen-specific >> plugin interface to dbus calls over stdio. > > By 'stdio' I mean the standard input and output streams that Unix > processes are provided with, not the stdio.h facilities :) > >> The only requirement is that such new >> loader should be able to perform p2p dbus communication over file >> descriptors - gsso daemon communicates with plugins using dbus over >> stdio. > > Same here. Read 'standard input and output' instead of 'stdio'. > > > Alex > <p> </p><p> </p> > <p> </p><p> </p> _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
