Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] route handler to support redirects #3993

Closed
tjenkinson opened this issue Sep 27, 2020 · 13 comments
Closed

[Feature] route handler to support redirects #3993

tjenkinson opened this issue Sep 27, 2020 · 13 comments

Comments

@tjenkinson
Copy link
Contributor

tjenkinson commented Sep 27, 2020

Context:

  • Playwright Version: 1.4.2
  • Operating System: Mac
  • Node.js version: 14.12.0
  • Browser: All

Code Snippet

const playwright = require('playwright');

(async () => {
  for (const browserType of ['chromium', 'firefox', 'webkit']) {
    const browser = await playwright[browserType].launch({ headless: true });
    const context = await browser.newContext();
    const page = await context.newPage();

    let seenRequest = false;
    page.route('**', (route) => {
      const url = route.request().url();
      if (url.includes('account.bbc.com')) {
        seenRequest = true;
      }
      route.continue();
    });

    await page.goto('https://www.bbc.co.uk/');
    await page.click('"Sign in"');
    await page.waitForRequest(/account\.bbc\.com/);
    if (!seenRequest) {
      console.error('Did not see request');
    }
    await browser.close();
  }
})();

Describe the bug

When clicking 'sign in' there is a 302 redirect from https://session.bbc.co.uk/session to https://account.bbc.com/.

It looks like the handler is not called again with the new url on the redirect.

The docs say:

If request gets a 'redirect' response, the request is successfully finished with the 'requestfinished' event, and a new request is issued to a redirected url.

So I'm expecting the handler to be called again with the new url.

I'm expecting "Did not see request" not to be logged in my example, but it is.

@tjenkinson tjenkinson changed the title [BUG] route handler not called for destination from 301 redirect [BUG] route handler not called for destination from 302 redirect Sep 27, 2020
@tjenkinson
Copy link
Contributor Author

tjenkinson commented Sep 28, 2020

I added a test for this in #3994

It looks like a new request event is fired, but the interceptor is not called for it.

@dgozman
Copy link
Contributor

dgozman commented Sep 30, 2020

As pointed in #3994, this is currently by design. Let me update this as a feature request.

@dgozman dgozman changed the title [BUG] route handler not called for destination from 302 redirect [Feature] route handler to support redirects Sep 30, 2020
@tjenkinson
Copy link
Contributor Author

@dgozman thanks. Is there a way of providing an allow list on urls that can be accessed (including redirects) and block the rest without needing to intercept?

@dgozman
Copy link
Contributor

dgozman commented Oct 1, 2020

There is no specific API for this. I think you can use proxy, although that's involved.

@tjenkinson
Copy link
Contributor Author

Looks like that could work by not setting up a server and using bypass as the allowlist.

The network interception in Playwright is implemented on the Browser -> Network stack boundary. Once the request is in the network stack, it is going to handle the redirects and report them, but not allow intercepting them.

Any tips on how we could support this? Sounds like something browsers would need to support first before playwright could hook into it?

@dgozman
Copy link
Contributor

dgozman commented Oct 2, 2020

Looks like that could work by not setting up a server and using bypass as the allowlist.

The network interception in Playwright is implemented on the Browser -> Network stack boundary. Once the request is in the network stack, it is going to handle the redirects and report them, but not allow intercepting them.

Any tips on how we could support this? Sounds like something browsers would need to support first before playwright could hook into it?

Exactly. This is specific to each browser's network stack, and requires investigation. Given the effort vs relatively small usecase, I don't expect this to be implemented in the near future.

@pavelfeldman
Copy link
Member

Closing it for now as per above...

@btomaj
Copy link

btomaj commented Oct 16, 2023

With the growing popularity of Remix (especially with the acquisition by Shopify), the use case for handling redirects is growing. Redirecting is a common pattern in Remix. Consider reopening, and finding a solution.

@schinckel
Copy link

I'd suggest that not doing this is broken from the perspective of doing OAuth mocking too.

If you have a page in your site that should trigger the OAuth process, then that needs to redirect to the OAuth server. However, it's impossible to do this using Playwright at this stage.

Please reconsider this issue - I can see the request using page.on('request', ...) but cannot intercept that.

@younes-zeboudj
Copy link

4 years later, no workaround or solution...?

@schinckel
Copy link

I actually came up with a workaround for this (and a related bug in the WebKit Playwright implementation), where instead of returning a redirect, you instead return a 200 (or whatever status code you like), and manually handle the redirect(s) in your test.

It's far less than ideal (I think I spent around 15 lines of code, specific to the test case, and another 10+ lines of comment), but at least it works.

@brendonmatos
Copy link

I actually came up with a workaround for this (and a related bug in the WebKit Playwright implementation), where instead of returning a redirect, you instead return a 200 (or whatever status code you like), and manually handle the redirect(s) in your test.

It's far less than ideal (I think I spent around 15 lines of code, specific to the test case, and another 10+ lines of comment), but at least it works.

Mind sharing your solution?

@standbyoneself
Copy link

I also need this feature in order to implement auto-selecting certificate

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants