Page Overlay ignores token_auth in URL when opened from a Widget #17640

Expected Behavior

When embedding Matomo widgets in an iFrame, it is expected that all links in the widget will work when using a token_auth with the correct permissions.

Current Behavior

When embedding Matomo widgets that contain links to view the Page Overlay (For example the Pages or Page URL reports) the Page Overlay links open in a new tab and force the user to log in instead of using the token_auth present in the URL.

This causes any users that are already logged in to Matomo but don't have access to the site to see You do not have access in the Page Overlay UI.
Users that are not logged in will see the error message Your session has expired due to inactivity. Please log in to continue.

Steps to Reproduce (for Bugs)

1. Embed the Page URL report as a widget in a page using a token_auth of a user that has view access to the report
2. Open the page that contains the iFramed widget in a private browsing session and click on a link to to a Page Overlay
3. You should be presented with the following error message if you are not logged in to Matomo:
   

Your Environment

• Matomo Version: 4.3.1

I'm not sure if the Page Overlay is meant to work in an iframe. ping @tsteur @mattab
But I guess the "problem" is that the overlay appends force_api_session=1 to various urls.

@Starker3 @sgiehl I just tested it using 4.2.1 and it worked there from what I can see so I'm assuming this might be a regression

Probably related to this PR: https://github.com/matomo-org/matomo/pull/17520

@tsteur I tested this on 4.2.1 and had the exact same error. I tried appending the token_auth to the end of the URL (Since the link from the widget adds a # with additional information at the end of the URL) as well and it returned the error Error: You must be logged in to access this functionality.

Weird, it worked for me there using

https://mylocaldomain/index.php?module=Widgetize&action=iframe&disableLink=0&widget=1&moduleToWidgetize=Actions&actionToWidgetize=getPageUrls&idSite=1&period=year&date=yesterday&disableLink=1&widget=1&token_auth=4a45307d01810d2307be558f9596e51f#

and then opening the page overlay. Tested this in a private window where you aren't logged in.

@tsteur and @Starker3 could you please check if the URL of the overlay page contains the force_api_session=1 and try it with or without it to reload the page?

actually 4.2 and 4.3 works for me nicely with only the token.
Also works when adding force_api_session=1 (because I don't have a session active anyway)

I can't reproduce the issue actually

@flamisz removing force_api_session=1 from the URL didn't make any difference when testing (On 4.2.1).
I got the same error from the URL with and without the force_api_session: Error: Your session has expired due to inactivity. Please log in to continue.
Tested using a private window (To ensure that there is no open session)

The link that is generated for the overview on both my testing instances is the following:
https://localhost/index.php?module=Overlay&period=month&date=today&idSite=1&force_api_session=1&token_auth=f1d1fd6c253df6d6aa3840aca258a046#?l=http$3A$2F$2Flocalhost$2Ftest$20page1.html

@tsteur the same for me, it works on the latest version with a view token even when the force_session_api=1 is in the url.

@flamisz If it helps narrow it down, I'm testing using localhost for the iFrame widget with an externally hosted Matomo install (Accessible from the internet).

OK I was able to reproduce it, had to turn off anom user (obviously) on my local environment. @tsteur @Starker3

great find @flamisz could you also git checkout 4.2.1 to see if it happens there too?

@tsteur it happens there as well. it's not a regression in my opinion.

Great, thanks @flamisz I moved it out of the milestone for now.

I think the token_auth should be appended to all URLs in Widgets that have it in the link or iframe widget. I think it should not create a new session as this could be confusing. If it starts a session, the view user would be logged in and potentially logged out of another account the person is using or be logged in when they were not.

We could use the force_api_session URL parameter to only allow this also. But then this parameter is required also.

If we append the token_auth to every URL, maybe it could be made part of a core JS library. However, this might prove tricky to do. Maybe an event that bubbles up the DOM could be caught and inject it so to speak, but this could be complicated to do and have other downsides later that we don't consider now.

The easy thing to do would be to just ask plugin developers to append any token_auth parameters to the URLs used in their plugins. We could add a function to the framework that does this automatically.

For example, a plugin dev could call something like:

var url = '/index.php?param1=value1&' + tokenAuth();

If we later have more URL parameters that need to be added, we could also generically do something like:

function appendAdditionalURLParameters(url) {
  return url + '&token_auth=...&other_matomo_url_parameters=values';
}

// usage
var url = appendAdditionalURLParameters('/index.php?something=else');

Of course the function name could be shortened to something like:

function aaup(url) {
  // ...
}

@geekdenz I'm not entirely sure but I think there are three issues:

issue 1

When you embed the widget eg like this:

index.php?module=Widgetize&action=iframe&disableLink=0&widget=1&moduleToWidgetize=Actions&actionToWidgetize=getPageUrls&idSite=1&period=year&date=yesterday&disableLink=1&widget=1&token_auth=7f4c29dfe7aea5d1400d561237b43446

then you click on overlay then the URL includes the force_api_session URL parameter which it shouldn't see below (it's not really a problem but it shouldn't contain this parameter in this case when it's not set in the original URL)

/index.php?module=Overlay&period=month&date=today&idSite=1&force_api_session=1&token_auth=7f4c29dfe7aea5d1400d561237b43446#?l=https$3A$2F$2Ffoobar$2Ftest.html

There is a method piwik.broadcast.isWidgetizeRequestWithoutSession() that we usually use to decide if we need to append force_api_session or not see example.

issue 2

The next problem is that it seems to call the startOverlaySession URL without any token in the URL

Request URL: /index.php?module=Overlay&action=startOverlaySession&idSite=1&period=month&date=today&segment=

This triggers an exception and the login screen to be shown (as it has the iframe buster on). Meaning plugins/Overlay/templates/index.twig should add the token_auth to the URL but it doesn't.

issue 3

Same applied to where it tries to render the sidebar in https://github.com/matomo-org/matomo/blob/4.4.1-rc1/plugins/Overlay/javascripts/Piwik_Overlay.js#L40-L53 --> a ajaxRequest.withTokenInUrl(); call should fix this likely.

It's probably not really to do with plugins but really with the implementation in overlay.js

Hope this helps

Thanks @tsteur . It does.

I found this setting:

[General]
enable_framed_pages = true

here:
https://github.com/matomo-org/matomo/blob/a35070be5146539999fdd02d5323f466d314192b/core/View.php#L458-L462

Should this be required for this to work?

I also found it in the Overlay code here:
https://github.com/matomo-org/matomo/blob/115527353a9e75e01aa4d263408956ae45403bea/plugins/Overlay/javascripts/Overlay_Helper.js#L31-L32

Otherwise we could add this parameter I assume:

module=Widgetize

Sorry, no adding the module parameter probably does not work as it is the Overlay module already.

Maybe we could just open it in the current window/tab if it is a widget? Would that make sense from a user's perspective?

While testing I changed the target to test instead of _blank then it was a bit easier to debug as you could then open the browser developer tools and see what is going on. Not sure if you meant that? I simply changed it for the "row action" element or maybe it works also to change the target here: https://github.com/matomo-org/matomo/blob/4.4.1/plugins/Overlay/javascripts/rowaction.js#L64

enable_framed_pages = true is not needed indeed.

The overlay helper you are referencing might need to be changed indeed 👍

@tsteur Please consider checking out my branch above. I have not created a PR yet, as there are no unit tests and I have not done extensive testing. You could check it out though to see if we're on the right track.

@geekdenz generally I think only a few changes in the Overlay plugin should be needed. All the other changes can be likely reverted. I'll also leave a comment in the code

actually be good to create a PR already so I can leave comments. You can then mark it as a "draft". It will then also run the overlay UI tests etc.