Issue 242 in accounts-sso: Please provide a way to dynamically update/delete methods/mechanisms based on pluginloader output

[accoun...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 242 by mon...@gmail.com: Please provide a way to dynamically
update/delete methods/mechanisms based on pluginloader output
https://code.google.com/p/accounts-sso/issues/detail?id=242

What steps will reproduce the problem?

1.Start gsignond
2.gsso-example --query-methods
3. Remove any libXXX.so from the plugin directory
4.gsso-example --query-methods, still shows the deleted plugin name
5. Restart gsignond and then gsso-example --query-methods works fine.


What is the expected output? What do you see instead?

gsignond should dynamically update method/mechanism list by queering
pluginloader instead of caching methods during gsignond startup.

What version of the product are you using? On what operating system?
Ubuntu, Tizen

Please provide any additional information below.
It seems gsignond_plugin_proxy_factory_get_plugin_types and
_enumerate_plugins uses some caching. May be
_GSignondPluginProxyFactory::methods_to_mechanisms, methods_to_loader_paths
and plugins resetting is required to disable the caching. Or may be some
API should be provided to remove methods/mechanisms. Kindly provide your
opinion.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[accoun...@googlecode.com]

Updates:
Owner: jussi.la...@linux.intel.com

Comment #1 on issue 242 by alex.kan...@gmail.com: Please provide a way to

dynamically update/delete methods/mechanisms based on pluginloader output
https://code.google.com/p/accounts-sso/issues/detail?id=242

I don't remeber why we have this caching. Maybe because enumerating plugins
through the plugin loader is expensive and slow?

Jussi, do you know?

BTW, you don't need to restart gsignond, I think sending SIGHUP is enough.

[accoun...@googlecode.com]

Comment #2 on issue 242 by mon...@gmail.com: Please provide a way to

dynamically update/delete methods/mechanisms based on pluginloader output
https://code.google.com/p/accounts-sso/issues/detail?id=242

Alex,
Will there be any problem if I send SIGHUP while some authentication
session is active (eg signonui dialog is active for say oauth plugin, in
the meantime someone deletes digest plugin and to reload the proper methods
I send SIGHUP to gsignond)

[accoun...@googlecode.com]

Comment #3 on issue 242 by alex.kan...@gmail.com: Please provide a way to

dynamically update/delete methods/mechanisms based on pluginloader output
https://code.google.com/p/accounts-sso/issues/detail?id=242

I think that's going to terminate all active sessions, but not otherwise
crash or hang anything. I don't know if you see that as a problem :)

We wrote gsso with the assumption that the set of available plugins changes
infrequently, and the change is coming from the system vendor through
package updates.

[accoun...@googlecode.com]

Comment #4 on issue 242 by mon...@gmail.com: Please provide a way to

dynamically update/delete methods/mechanisms based on pluginloader output
https://code.google.com/p/accounts-sso/issues/detail?id=242

Alex,

Thanks for the reply.

Well if its going to terminate the active sessions then thats problem for
us :(

I understand the motivation behind caching.
However since gSSO opened up plugin loader so its a possibility that some
plugin loader implementation may allow 3rd party plugins, hence its
required to eliminate the method name caching.
So it would be great if this feature can be implemented (or may be some
mechanism can be provided to plugin loaders so that it can notify gsignond
whenever plugin caching needs to be reloaded, without affecting the ongoing
sessions)

Have a nice day.

[accoun...@googlecode.com]

Comment #5 on issue 242 by alex.kan...@gmail.com: Please provide a way to

dynamically update/delete methods/mechanisms based on pluginloader output
https://code.google.com/p/accounts-sso/issues/detail?id=242

But what is the use case here? When would you want to update the plugin
list without affecting ongoing sessions?

Do you need a plugin loader that for some reason changes the list of
available plugins frequently? Why?

[accoun...@googlecode.com]

Comment #6 on issue 242 by mon...@gmail.com: Please provide a way to

dynamically update/delete methods/mechanisms based on pluginloader output
https://code.google.com/p/accounts-sso/issues/detail?id=242

In our case, the plugins are down-loadable (which can be installed /
uninstalled by the user), hence "--list-plugins" output may vary.

However it appears that gsignond does not call "--list-plugins" for every
signon_auth_service_query_methods() call and instead do caching (may be due
to performance constraint)

So for a plugin loader providing down-loadable plugins, it seems that extra
check is required (from our side) to make sure that
signon_auth_service_query_methods results are valid.

[accoun...@googlecode.com]

Comment #7 on issue 242 by alex.kan...@gmail.com: Please provide a way to

dynamically update/delete methods/mechanisms based on pluginloader output
https://code.google.com/p/accounts-sso/issues/detail?id=242

One of the design goals of gsso is that authentication plugin management is
completely hidden from the end user. The user should never need to
install/uninstall them, or even know that there are plugins. We expect that
the OS vendor would take care of providing the plugins, and also make sure
the daemon is notified when there is a change in available plugins.

Can you explain how your system of downloadable plugins works and what is
the benefit for the user? Maybe you have some code/screenshots/examples?

[accoun...@googlecode.com]

Comment #8 on issue 242 by mon...@gmail.com: Please provide a way to

dynamically update/delete methods/mechanisms based on pluginloader output
https://code.google.com/p/accounts-sso/issues/detail?id=242

Our use case is to let 3rd party developer deploy their own custom plugins:
bundled with their application(s).

So when the application gets uninstalled by the user we should remove the
plugin too.
(user installs application A, A's bundle deploys libAPlugin.so too, user
uninstalls A, we should remove libAPlugin.so too. Note: libAPlugin.so can
be used by only A's affiliated apps)

BTW, instead of calling signon_auth_service_query_methods() ,
we can directly contact plugin loader with --list-plugins and it can list
the correct plugin list, but Im not sure whether bypassing gSSO for this
will affect anything else.

It would have been ideal if gsignond could provide a feature similar to
SIGHUP but without affecting existing session (Please note, of-course we
have no problem if it ends all libAPlugin related session, but it should
not end say liboauth related ongoing sessions, if any)

Thanks.

[accoun...@googlecode.com]

Comment #9 on issue 242 by alex.kan...@gmail.com: Please provide a way to

dynamically update/delete methods/mechanisms based on pluginloader output
https://code.google.com/p/accounts-sso/issues/detail?id=242

I see, that makes sense. We'll either remove the 'caching' or provide an
official way to refresh the plugin list without reinitializing the daemon.
I'll get a comment out of Jussi.

Of course, custom plugins should only be written for custom, proprietary
authentication protocols (something like iTunes). If what the app is doing
is described in a public document, and not specific to the application,
then there should be a common, shared plugin provided by the OS, like oauth.

Does this look ok to you?

[accoun...@googlecode.com]

Comment #10 on issue 242 by mon...@gmail.com: Please provide a way to

dynamically update/delete methods/mechanisms based on pluginloader output
https://code.google.com/p/accounts-sso/issues/detail?id=242

Alex,
It would be great if you can provide that, so that we don't need to contact
pluginloader directly :)

I will keep watching this space for updates regarding this fix/enhancement.
Thanks for your help.

[P.S : Yes of-course, we will be providing support for both standard and
custom protocols]

[accoun...@googlecode.com]

Comment #11 on issue 242 by jussi.la...@linux.intel.com: Please provide a

way to dynamically update/delete methods/mechanisms based on pluginloader
output
https://code.google.com/p/accounts-sso/issues/detail?id=242

I think best solution is to add inotify hook to watch the plugin folder and
update the plugin list on-demand. This should be fairly simple thing to do.

(Alex, you can see tlm code where I did similar thing binding inotify with
glib for watching files in a folder)

[accoun...@googlecode.com]

Comment #12 on issue 242 by alex.kan...@gmail.com: Please provide a way to

dynamically update/delete methods/mechanisms based on pluginloader output
https://code.google.com/p/accounts-sso/issues/detail?id=242

That requires that plugin loaders tell the daemon what directories it
should be watching, so also a (small) addition to the loaders' API is
needed.

[accoun...@googlecode.com]

Comment #13 on issue 242 by alex.kan...@gmail.com: Please provide a way to

dynamically update/delete methods/mechanisms based on pluginloader output
https://code.google.com/p/accounts-sso/issues/detail?id=242

BTW, no need to use inotify directly, gio has
https://developer.gnome.org/gio/stable/GFileMonitor.html

[accoun...@googlecode.com]

Comment #14 on issue 242 by mon...@gmail.com: Please provide a way to

dynamically update/delete methods/mechanisms based on pluginloader output
https://code.google.com/p/accounts-sso/issues/detail?id=242

Hello Alex, Jussi,

Will there be any fix available for this feature? (I can see its not
yet "accepted").

BTW, I dont know about the broader picture, but for our specific need it
will be better if you remove caching instead of monitoring a directory for
plugin changes. Because we can not store our custom plugins (which in our
case are packaged applications) in one specific directory.

-Thanks

[accoun...@googlecode.com]

Comment #15 on issue 242 by alex.kan...@gmail.com: Please provide a way to

dynamically update/delete methods/mechanisms based on pluginloader output
https://code.google.com/p/accounts-sso/issues/detail?id=242

The monitored directory that a plugin loader reports to gsso does not have
to be a directory with actual plugin binaries.

It can be some other directory entirely, and whenever a plugin loader needs
to trigger a plugin list update, it can just overwrite some small file in
that directory.

Otherwise, I was about to start implementing this today or tomorrow, but
now I need confirmation from you :)

[accoun...@googlecode.com]

Comment #16 on issue 242 by alex.kan...@gmail.com: Please provide a way to

dynamically update/delete methods/mechanisms based on pluginloader output
https://code.google.com/p/accounts-sso/issues/detail?id=242

Oh, and it doesn't have to be a directory. The plugin loader can supply a
file path instead, and then just that one file will be watched. For example
if you have a plugin registry file of some sort, that can be used too.

[accoun...@googlecode.com]

Comment #17 on issue 242 by mon...@gmail.com: Please provide a way to

dynamically update/delete methods/mechanisms based on pluginloader output
https://code.google.com/p/accounts-sso/issues/detail?id=242

Alex,

If you are suggesting about something like vconf (or inotify), then that
would be ideal for us.

Thanks for the update :)

[accoun...@googlecode.com]

Comment #18 on issue 242 by alex.kan...@gmail.com: Please provide a way to

dynamically update/delete methods/mechanisms based on pluginloader output
https://code.google.com/p/accounts-sso/issues/detail?id=242

I'm suggesting that a plugin loader will provide to gsso a file path (or a
directory path) that gsso will be watching for changes using inotify.

So executing '/path/to/plugin/loader --plugin-refresh-path' will print the
path to watch on standard output, same as when using --list-plugins option.

When a change in that file or directory is detected, gsso will refresh the
list of plugins by requesting the new list from the plugin loader. So if
you can't think of a directory to watch, provide a file path instead. What
that file contains, and how it's managed is up to you.

[accoun...@googlecode.com]

Comment #19 on issue 242 by mon...@gmail.com: Please provide a way to

dynamically update/delete methods/mechanisms based on pluginloader output
https://code.google.com/p/accounts-sso/issues/detail?id=242

Sounds great. I will keep watching this issue id for the update.
Thanks.

[accoun...@googlecode.com]

Updates:
Status: Accepted

Comment #20 on issue 242 by alex.kan...@gmail.com: Please provide a way to

dynamically update/delete methods/mechanisms based on pluginloader output
https://code.google.com/p/accounts-sso/issues/detail?id=242

Okay then. This issue is Officially Accepted For Development :)

[accoun...@googlecode.com]

Comment #21 on issue 242 by mon...@gmail.com: Please provide a way to

dynamically update/delete methods/mechanisms based on pluginloader output
https://code.google.com/p/accounts-sso/issues/detail?id=242

Great :)

[accoun...@googlecode.com]

Updates:
Status: Fixed

Comment #22 on issue 242 by alex.kan...@gmail.com: Please provide a way to

dynamically update/delete methods/mechanisms based on pluginloader output
https://code.google.com/p/accounts-sso/issues/detail?id=242

Here it is:

https://code.google.com/p/accounts-sso/source/list?repo=gsignond&name=dynamic-plugin-update

Please check that
a) it works for you (no crashes or freezes);
b) it does what you want (behaves as expected)

[accoun...@googlecode.com]

Comment #23 on issue 242 by mon...@gmail.com: Please provide a way to

dynamically update/delete methods/mechanisms based on pluginloader output
https://code.google.com/p/accounts-sso/issues/detail?id=242

Alex,
Thanks for the fix, I will verify on monday and update.