Incorrect redirect to malformed url within AUT - adding _/ in url

[hhudson]

Current behavior:

When I instruct cypress to login to an Oracle APEX application, the authentication re-directs cypress to a '404 not found' page because the authenticated URL is malformed. The malformed URL is the only issue and can simply corrected programmatically (with a find and replace command).

However - it is very important to note that the cypress login correctly returns:

1. a valid cookie
2. a valid session

which is everything you need for authentication.

Desired behavior:

Cypress, ideally, should be able to follow the same authentication redirect that a user would in a regular browser.

Steps to reproduce: (app code and test code)

I created a dummy application with dummy credentials hosted by apex.oracle.com to demonstrate:

it('Login demo', function() {
    cy.visit('https://apex.oracle.com/pls/apex/f?p=54707:LOGIN_DESKTOP')
    cy.get('#P9999_USERNAME').type('ApexUser')
    cy.get('#P9999_PASSWORD').type('Oradoc_db1')
    cy.get('.t-Button').click()
  })

The above code (which should work until the application expires in many months) will redirect to a 404 not found page with a url in the format:
https://apex.oracle.com/__/f?p=54707:1:[session_id]:::::
Outside of cypress the url will have the format:
https://apex.oracle.com/pls/apex/f?p=54707:1:[session_id]:::::

Versions

I have tested this across 4 instances of Oracle APEX (APEX 5.0, 5.1, 18.1 and 19) and this behavior is consistent.

[MaikMichel]

I face the same problem. But only when using chromium. If I use elektron, it works.

[hhudson]

I face the same problem. But only when using chromium. If I use elektron, it works.

That is very good to know. Just teste on Electron 59 to confirm that this works for my case as well. Thank you, @MaikMichel

[jennifer-shehane]

Another issue where 404 is returned due to malformed url containing /_/ #4472

[jennifer-shehane]

I can recreate this issue from the original code provided in the main comment. This is still happening in 3.3.2 pre-release version.

[jennifer-shehane]

Since this issue only exhibits itself within Chrome - we figure it is a change in Chrome that caused this issue to happen in Cypress. I also assume it is not a bug, as the issue still persists in version 77. It may be an intended change in behavior.

Narrowing down the version of Chrome that it was introduced, it was introduce in version 71.0.3572.0, specifically between commits 7e3da6dc3d7cd7eb8a55ef301026fe1ab737f814 and 56dd83c9005f68d55ddbf85c551759526b4e37cd:

• Chrome 61.0.3163.100 - PASSES
• Chrome 69.0.3452.0 - PASSES
• Chrome 71.0.3572.0 - PASSES = Base = 597039 7e3da6dc3d7cd7eb8a55ef301026fe1ab737f814
• Chrome 71.0.3572.0 - FAILS = Base = 597057 56dd83c9005f68d55ddbf85c551759526b4e37cd
• Chrome 72.0.3583.0 - FAILS
• Chrome 73.0.3683.0 - FAILS
• Chrome 74.0.3729.0 - FAILS
• Chrome 77.0.3833.0 - FAILS

⭐️ Changelog where issue was introduced

@flotwig good luck 😅

[hhudson]

Wanted to check back in and confirm that the issue has been resolved in the Chrome 77 browser. Thanks!

[drumbeg]

Issue now present in Cypress 3.5.0 when using Electron.

[drumbeg]

Please re-open this issue. It is apparent in Electron 73 that ships with Cypress 3.5.0.

[flotwig]

Re-opening since others are still running in to this: #5442

[hhudson]

With the new 3.6.0 update, the problem has both regressed and gotten worse, unfortunately. This behavior manifests in both the electron and chrome browsers (when I 1st opened this issue, the issue was restricted to the chrome browser)

[drumbeg]

With the new 3.6.0 update, the problem has both regressed and gotten worse, unfortunately. This behavior manifests in both the electron and chrome browsers (when I 1st opened this issue, the issue was restricted to the chrome browser)

Hayden, do you have a workaround for the issue? I noticed you mentioned programatically replacing part of the url. I'm trying to get this to work, but no luck yet.

[hhudson]

With the new 3.6.0 update, the problem has both regressed and gotten worse, unfortunately. This behavior manifests in both the electron and chrome browsers (when I 1st opened this issue, the issue was restricted to the chrome browser)

Hayden, do you have a workaround for the issue? I noticed you mentioned programatically replacing part of the url. I'm trying to get this to work, but no luck yet.

David - currently my workaround is to use Cypress version 3.4.1, which does not have this issue.

Were I to upgrade, I think I could still live with it because Cypress is technically logging in successfully, i.e. the session id is valid. Therefore, if my purpose is simply to reach pages other than the login page, I can construct a valid url using the session id (and setting the cookie, of course).

[drumbeg]

With the new 3.6.0 update, the problem has both regressed and gotten worse, unfortunately. This behavior manifests in both the electron and chrome browsers (when I 1st opened this issue, the issue was restricted to the chrome browser)

Hayden, do you have a workaround for the issue? I noticed you mentioned programatically replacing part of the url. I'm trying to get this to work, but no luck yet.

David - currently my workaround is to use Cypress version 3.4.1, which does not have this issue.

Were I to upgrade, I think I could still live with it because Cypress is technically logging in successfully, i.e. the session id is valid. Therefore, if my purpose is simply to reach pages other than the login page, I can construct a valid url using the session id (and setting the cookie, of course).

How would you do this? Do you have an example? I have tried logging in and then replacing the page name in the url whilst keeping the session section whilst also preserving the cookie. I still can't get around the issue though, so if you have a working workaround I would love for you to share it.

[drumbeg]

Tested on 3.6.1. Bug is still apparent.

Was expecting 3.6.1 to contain a resolution for this, but maybe confusing issues.

Our 50 developers are keen to see a fix!

[jennifer-shehane]

If you're experiencing this bug still, please open a new issue with a fully reproducible example that we can run. There may be a specific edge case with the issue that we need more detail to fix.

[Yann39]

I am also facing this issue with all browsers including Electron :

• Electron
• Edge 85 (85.0.564.41)
• Chrome 85 (85.0.4183.83)
• Firefox 80 (beta)

Cypress 4.7.0
Node v8.11.3

Same after upgrading to latest versions:
Cypress 5.1.0
Node v12.18.3

it('Login page', () => {

        // visit main home page
        cy.visit('https://tstapex.myhost.ch/ords/f?p=119')

        // make sure we are redirected to login
        cy.url().should('include', 'LOGIN_DESKTOP')

        // log in
        cy.get('#P9999_USERNAME').type('username')
        cy.get('#P9999_PASSWORD').type('password')

        // click login button
        cy.get('#login-button').click();

    })

I'm redirected to https://tstapex.myhost.ch/__/f?p=119:1:28275213605974:::::

Then of course get:

Not Found
The requested URL /__/f was not found on this server.

Setting experimentalSourceRewriting to true does not help.

[gcoombe]

Are there any other workarounds? We can't use the experimental flag since apparently it breaks with react-router #7906 . Currently Cypress just breaks for us on a number of pages.

[intoeetive]

Not really a solution, but following approach worked for me:

cy.wait(20000);
cy.visit(my_url);

[cypress-bot]

The code for this is done in cypress-io/cypress#15995, but has yet to be released.
We'll update this issue and reference the changelog when it's released.

[jennifer-shehane]

If you'd like to try the fix from the #15995 PR before the release, you can follow these instructions to download a pre-release version of Cypress.

[jennifer-shehane]

Released in 7.3.0.

This comment thread will been locked. If you are still experiencing this issue after upgrading to Cypress v7.3.0, please open a new issue.