Widgetize: giving access to everybody to view a specific widget (token_auth on a per widget basis) #5703
Comments
|
I'd like to allow the Drupal user to save it's own token_auth in his Drupal user settings. If the User take a look on the reports all the reports need to be accessed with the token_auth. This solution is much better than opening the full system for all anonymous users. Today this seems not working. If I read the above it should work... sounds like something is broken. Additional to my "quick" solution it would be great to have the ability to define what widget is accessible by anonymous users. |
|
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. |
|
Also an issue on API calls. Keep in mind that the Drupal Piwik Reports module attaches the token_auth to the JSON URLs to get JSON data that will be processed in a loop to build a HTML table and fill it with the data I receive from Piwik. This is "Ajax" with an auth key. |
|
See here how this works (I'm grabbing the URL with token_auth from a plain text value in source code): |
|
(In [1300]) moving auth refs #5703 |
|
i didnt find this old ticket via search anyway - i described pretty much the same problem |
|
I definitely love to have this feature. I am building a web app that using piwik to show the statistics widgets to the users. Let me know if I can help in anything. |
|
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 |
|
token_auth works with widgets, postponing this feature request to later |
|
+1 |
|
@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. |
|
Two related topics on the forum: |
|
This issue has been mentioned on Matomo forums. There might be relevant details there: https://forum.matomo.org/t/wordpress-embed-visitor-map/46922/4 |
|
This issue has been mentioned on Matomo forums. There might be relevant details there: https://forum.matomo.org/t/wordpress-importing-piwik-data/26791/12 |
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.
Specification- 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.).
- 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
The text was updated successfully, but these errors were encountered: