Host permission wildcard URL pattern - any ideas will help please

[Satish Sallakonda]

Hi All -

We have a customer who uses Workday HCM software and our BE extension is supported on this system. Recently, as a part of their go-live testing, the URL's in different environments looked like https://<hidden>.workday.com/<tenant>/d/home.htmld and tenant name would vary by environment names. Once they went live the domain entirely changed to https://<hidden>.myworkday.com/<tenant>/d/home.htmld, this means the way we defined our host permission URL match just didn't work and our go-live came to halt. Here is what we have in manifest file in chrome store

"http://*.workday.com/",

"https://*.workday.com/*",

"http://*.workday.com/*/*",

"https://*.workday.com/*/*",

Now we need to add the new host URL and deploy to chrome store, with the long delays in review cycle this is just not scalable as we have other customers and especially if these URL's are changing on different environments. 

One option is to define wildcard like this http://*.*workday*.com/" but this is not permitted as mentioned in this article  https://developer.chrome.com/extensions/match_patterns

Any ideas on best way to resolve this and avoid such traps to deploy to chrome store every time we discover new URLs or accelerate review process. We have this huge warning in developer dashboard against our extension "Due to the Host Permission, your extension may require an in-depth review which will delay publishing."

Thanks!

[PhistucK]

I am not sure there is much you can do. If this is an extension per customer, then do not use wildcards at all and include all of the specific hosts (across all of the test/production environments).

If this is an extension per multiple customers and the host changes per customer, use the wildcard and bear with the review times (I heard they can be surprising sometimes, for the better).

Another option is to tell your customers to have their administrator force-install the extension. You can then provide them with a CRX file that you generated, without any review. You will have to update them manually and they will have to put the updated CRX in the relevant path (though this can obviously be automated).

One tip regarding host permissions - as far as I know, anything after the host is ignored (this is why they are called host permissions), so no need to include -

"https://*.workday.com/*",
"http://*.workday.com/*/*",
"https://*.workday.com/*/*",

Just -

"http://*.workday.com/",

"https://*.workday.com/"

(Obviously, try to avoid the HTTP version at all)

Content scripts use URL match patterns, not host match patterns and there the trailing /* and similar are required.

Also, if you declared content scripts for a certain host (its URLs), you do not need to include those hosts in the permissions key, they are intrinsically included.

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/994a2f01-83b0-4615-8d7f-9ad318fd68dfn%40chromium.org.

[wOxxOm]

You can probably use include_globs as shown here. One big problem though is that it requires all_urls permission so maybe not so great an idea.

BTW 1) you can use * to match both http and https: *://*.workday/* so this single pattern will match all the four variants in your post because the final * matches any amount of characters in the path including 0 and slashes.

[Satish Sallakonda]

Thanks Phistuck! Appreciate your input. Following up on your feedback "If this is an extension per multiple customers and the host changes per customer, use the wildcard and bear with the review times (I heard they can be surprising sometimes, for the better). " 

1) Our extension is per multiple customers and the host changes per customer. Are you suggesting to try https://*.*workday*.com (so that would cover any variation of Workday) or something else I'm missing. What are the risks of getting rejected or will it get through if we explain this scenario to them.

2) Are there risks with using all_urls permission. 

[PhistucK]

See inline.

☆PhistucK

On Tue, Oct 27, 2020 at 6:50 PM Satish Sallakonda <sallakon...@gmail.com> wrote:

Thanks Phistuck! Appreciate your input. Following up on your feedback "If this is an extension per multiple customers and the host changes per customer, use the wildcard and bear with the review times (I heard they can be surprising sometimes, for the better). " 

1) Our extension is per multiple customers and the host changes per customer. Are you suggesting to try https://*.*workday*.com (so that would cover any variation of Workday) or something else I'm missing. What are the risks of getting rejected or will it get through if we explain this scenario to them.

I am not sure *workday* is supported (I have not checked), but I thought the prefixes are per environment (test or production). If you need a lot of flexibility, then I guess <all_urls> is the only option (unless those wildcards are supported).

I think the dashboard requires you to explain each permission (not sure about specific host permissions), so that might get you through.

 

2) Are there risks with using all_urls permission. 

The review will be even stricter with that permission, but it may pass if the reviewer thinks it is fine (with your explanation). No idea..

[Phillip Boateng]

I think <all_urls> is commonly used as Phistuck mentioned, as long as your clear in your explanation it should be fine. 

The only issue is the review process may take longer than normal.

[Satish Sallakonda]

Thanks Phistuck, Phillip and wOxxOm! Appreciate all the input. I played safe, went ahead and added *.workday.com to host permission and submitted for now. It's in pending review, now the wait continues.

Virus-free. www.avg.com

Virus-free. www.avg.com

[Satish Sallakonda]

Sorry I meant to say *.myworkday.com

Virus-free. www.avg.com