@mattab opened this issue on July 6th 2008

At the moment, users can only export widgets if they have made their statistics publicly available. Often, people would be happy to share their number of visits (and show the evolution graph over the last 30 days for example), but they don't want to share other data (keywords, referers, etc.).

At the moment widgets are shown only if stats are avaialble for the anonymous user, or if the user passes its token_auth to the widget. This is a problem as currently token_auth is like having the login + password.

Proposal - each website is associated with a website_key that has VIEW access to the website data. - this key is the one passed for invoking the widgets. - it is expected that this key is Known to external users. Having this key means that all the website reports are readable. - during Authentication, in: /plugins/Login/Auth.php there will be a new sql query to select from piwik_site and try and match a website key; if matched, the login used is anonymous. anonymous user has read access but no write access (you can't create websites, users, goals, etc.).

Specification - DB changes: new token_auth field of 32 chars in piwik_site - Migration: this token_auth must be randomly generated for all existing websites during migration. - API: the token_auth is now returned in the website responses from the SitesManager API, eg. in SitesManager.getSiteFromId(). When adding a new website, the token_auth must be generated. - Authentication: should be a small change in plugins/Login/Auth.php. Side note: we make sure that when the token_auth is empty in the DB (in case of migration issue for example), the authentication fails. - UI: the website_key is now added to all widgets embed fields URLs (for flash invocation, and iframe invocation)

Downside

The downside of this method is that the website_key is available to see all widgets for a website. This is rather open and will be an issue for some websites which will claim that it is not ok to open all the reports to everyone. The alternative would be to have a md5 hash generated for each tuple (widget, website), the Auth would then look in this list to authenticate.

if anyone is interested and wants to build this feature, let us know in the comments

@robocoder commented on July 2nd 2009

Escalating urgency of resolution.

A better(?) "token_auth" might be: md5(token_auth . widgetName), as it would not require an external site to store a copy of the Piwik user login & password.

@mattab commented on July 8th 2009

(In [1300]) moving auth refs #5703

@mattab commented on March 4th 2010

nass you are right. Until this feature is implemented, we should at least allow token_auth authentication in Widgetize calls, to allow widgets to be displayed with the token_auth of a user with view permissions. I reopened #235

@mattab commented on March 30th 2010

token_auth works with widgets, postponing this feature request to later

@DaSchTour commented on March 19th 2013

+1 with the realtime map widget this would be a great feature please add this soon

@halfdan commented on September 2nd 2013

@vipsoft: md5(token_auth . widgetName) is not a good solution. If you change your password, all shared widgets will become invalid. We should generate a new random access key on a per widget basis.

Powered by GitHub Issue Mirror