URL: query string too long

[Anonymous]

Hello everyone,

I am currently building a Power Apps app and have a problem with a link that shows and filters one of my Power BI reports. Two problems, actually. Please redirect me if I am at the wrong place here.

One problem is that sometimes that I get a message of failed login when trying to access the filtered report. I get the following error message for the sign-in link: AADSTS90015: Requested query string is too long. This problem exists across browsers and does not seem to come from the browser limit for URL lengths.

It seems like one can access the link after signing in to Power BI in a separate browser tab but this is more of a workaround than a solution. Some searching lets me believe that this is an issue connected to the Azure AD login and at several places about changing a web.config file. However, since I am not well-versed in administration (I don't have administrative rights in my organization anyways) I would like to know if there is a way to fix this; even better if I can fix it myself.

The other problem is that the filter-query of the URL can get quite long, due to how it is dynamically created in the app, and if it gets too long the report does not load anymore. With Edge, I receive the following

(roughtly translating into "This website of app.powerbi.com was not found. For the following address no website was found: <the filtered report URL>).

According to the documentation, there should be no limit to the URL length for the filter and I am only using one condition: <column_name> in <list_of_values>.

I am happy for any advice or suggestion on how to approach either problem.

[v-kelly-msft]

Hi @Anonymous ,

Check the similar thread below:

For question1:

https://social.msdn.microsoft.com/Forums/en-US/c87061d5-85ec-4557-b435-cf4e9d64a366/azure-app-registration-aadsts90015-requested-query-string-is-too-long?forum=WindowsAzureAD

For report filter(question2):

https://community.powerbi.com/t5/Service/URL-Filter-not-working/m-p/214195

Best Regards,
Kelly

Did I answer your question? Mark my post as a solution!

[Anonymous]

Hi @v-kelly-msft ,

thank you for your reply.

For question 1: I have already seen that thread (and similar ones) during my previous research but could not figure out where to find the web.config in question. I am developing a Power Apps canvas app, not a portal app. Maybe I should post this in the PowerApps forum instead?

For question 2: My filter works just fine and I am accessing the report, not the dashboard (which was the problem in your linked thread). The problem only occurs, when there are too many items in the list to filter by.

Best Regards,

DefinitelyNoBot

[v-kelly-msft]

Hi @Anonymous ,

For question 1:

If you could post a thread also in PowerApps forum,it would be a better choice for you as our related personnel would give you a better solution.

For question 2:

Check the limitations below:

• Report URL filters have a 10-expression limit (10 filters connected by AND).
• The long data type is (2^53-1) due to JavaScript limitations.
• Power BI doesn't limit the number of characters in URL query strings. Different browsers have different length restrictions.

Below is the related reference:

https://docs.microsoft.com/en-us/power-bi/collaborate-share/service-url-filters#considerations-and-troubleshooting

Best Regards,
Kelly

Did I answer your question? Mark my post as a solution!

[Anonymous · Accepted solution]

Hi @v-kelly-msft ,

thank you for your help!

None of the above-mentioned conditions seemed to be violated. However, I found a solution, albeit by accident rather than on purpose. 

It was decided that the report was to be published in a different workspace. Additionally I now use the link for embedding, rather than the direct link to the report. So the link looks like https://app.powerbi.com/reportEmbed?reportId=<...>&filter=<...>instead of https://app.powerbi.com/<...>/reports/<...>/ReportSection?filter=<...> .

I don't know which of the two changes resolved it, and I still don't know what caused it in the first place, but maybe this still helps some other reader in the future.

Best Regards