As I understand it, what you're asking for is to undo #235. This was done to secure Piwik against unintended (unauthorized) access to other widgets because token_auth is exposed to anyone who can view a page's source; effectively, the site might as well provide anonymous view access. Piwik has no way of knowing whether an embedded widget appears on restricted access page or not.

Even if it were a trivial matter of reverting [576](it isn't, I tried), we don't want go back as that would only renew allegations of a "security vulnerability"...

#283 proposes to combine authentication and authorization without disclosing token_auth.

It doesn't matter much if it's in the source or not as the users enters his own auth key into it's own user settings. They know about their key (readable in plain text in user account settings of piwik) and it's also still in the source for jquery.

In other places I'm doing a JSON API call $.getJSON() with the token_auth in the plain HTML code, parse the result and build a HTML table with the data. So if you care about such an invalid security also remove the token_auth from the API call.

This is all pretty stupid. Google API also have an auth key if you'd like to call for the data.

I really do not like to provide a patched Piwik version on the Drupal site only to allow the integration with remote systems.

If you can tell me a technical way how to call a remote site with authentication without an auth key, but with user authentication (_impossible_) you are a HERO. Let me know how you do this... I may learn.

This case is not invalid. You break external modules.

Warning: No permission to change ticket fields.

We recommend only using token_auth in Piwik API calls from the server.

If we're talking about Google Analytics data export API, Google's position on OAuth is:

Because OAuth requires a signature, and the signature key cannot be kept secure in a JavaScript environment, there is no native support for OAuth in Javascript.

There are obviously details to be worked out in #283. If it was trivial, it would have been implemented already. In the end, we might have to implement something Google-like, e.g., AuthSub or Shindig authentication proxies.

And I do apologize for the inconvenience this change has caused. However, it was not a recent decision (circa July 2008).

hass, you're right that this is bad to break your useful drupal stuff and vipsoft explained to you well the situation: the reason we did #285 is a real security issue as the token_auth should never be disclosed publicly.

We need to do #283 if this is a real issue for third party. I will think about it.