Auditing Pages behind helix microsoft authentication

[vhargrave]

Hi everyone. 👋
To my knowledge, we used to always declare the preivew link as our test URL and a LH test & report would be created directly on the pull request. Since putting preview URLs behind microsoft auth it's not possible for LH reports of the page to be run, and if a developer accidentally declares .page as their test urls then LH tests are actually being run on the microsoft login page, which isn't ideal.

Fortunately, AEM has a service that runs on AEM infra and can audit a page that's behind the helix microsoft authentication. You can read more about it here, if you're interested: https://culture-tecture.adobe.com/en/publish/2023/10/31/aem-pla-blog-lighthouse-everywhere-edge-delivery-and-the-eaas-aem-lighthouse-service
The aem code sync bot is integrated with it, but it requires a hidden feature flag to be enabled - has to be done on the global list.

I think from the express side we'll probably want to get this activated, but I'm creating this thread in case other sites are also interested.
@tuicu @adulvac are the two aem devs who can help us with this.

cc: @auniverseaway @narcis-radu @overmyheadandbody @mokimo @yesil @honstar @meganthecoder

[overmyheadandbody]

This might be a temporary solution, though. Helix 5 will remove Sharepoint authentication altogether and move to a Sidekick one. Right now it's not 100% clear how that will work, so this suggested implementation might not cover the upcoming Helix upgrade. In the meantime, could we not ask developers to publish their test documents inside the drafts folder and have PSI checks on the .live links?

I'm not opposed to it, but I just wonder if it's worth having it and then swapping it for a different solution in the near future.

[dulvac]

Hey @overmyheadandbody . Our service is a drop-in replacement for pagespeed as the impl of the code sync bot. And it has been used for a while by a few edge delivery services customers. There's 0 investment from users (adobecom developers) - they wouldn't even know which one is used on the PR. We can just do it with a feature flag switch, so the upfront cost is also 0.

For previewing (content creators, not developers), that's a different discussion. But AFAIK, even with helix 5, they want to keep API key authn, which is also something we support. Also, we are planning on making the PSI service work with helix 5 too.

[overmyheadandbody]

Thanks for the details, @dulvac! If your solution is forwards-compatible, then I'm good with going with it, since it would bring back LH scores to PRs quickly. Let's see if there are other opinions and, if not, we can likely move forward with this.

[mokimo]

Thanks for the additional info @dulvac - sounds cool, we had issues with authenticated PSI checks and been thinking of a solution.
This comes at a great time!

[narcis-radu]

I noticed some issues with generating reports when using the standard Milo urls. I have reached out to the team via Slack and will update the thread once I have a good understanding.

In the meantime, if we are going to implement this solution, I think it would make sense to deliver it to all Milo consumers instead of just Milo. We should plan some communication to make sure everyone is aware of the of the change and benefits.

[mokimo]

Let's start with @vhargrave use case of express, expand it to milo core and then roll this out to consumers once we see this working in action on those two projects.

[narcis-radu]

@mokimo - my concern with enabling this on Milo only is that we might see different results when using ?milolibs= with Milo consumers.

[mokimo]

Given an earlier discussion with @robert-bogos @narcis-radu & @overmyheadandbody in one of our meetings, we were wondering what the added benefits for this integration are.

Given most consumers (cc, dc, bacom, etc.) already use .live links for the PSI checks ( example: adobecom/cc#276 ) we wonder if this new PSI tools adds any benefits compared to using the standard one.

@dulvac any opinions on advantages / disadvantages?

[dulvac]

@mokimo , auditing pages behind (different types of) authentication is the main benefit right now. And a perceived advantage for the more privacy-conscientious users with the fact that we keep all data in-house, as the PSI service runs on adobe infrastructure. We don't have that need now, but we could also define in-house QoS with custom rate limits and allow more requests per second than google allows. But that would have to be coordinated with us scaling things up in the backend, if we have such a use-case.

It's important to understand that this is a drop-in replacement for the code sync bot and it is literally 0 effort to switch the backend back and forth any time between pagespeed and PSI via a simple feature flag. As a matter of fact, this is not even a customer configuration, it's an internal helix one. So if you have pages behind helix auth, to me this is a no-brainer to enable. Of course, we wouldn't make changes without the customer (you, in this case) approving it.

BTW, the issue with query params in urls was fixed today and deployed to prod. So now urls like https://mwpw-146756--milo--narcis-radu.hlx.page/eg_ar/drafts/narcis/page?martech=off work correctly.

HTH