question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

URI hash fragment doesn't seem to be redirecting

See original GitHub issue

Describe the problem

When redirecting to my application, the url hash fragment doesn’t seem to be consumed by Auth0Provider.

What was the expected behavior?

I guess I’m not sure what I should be doing on my app when auth0 redirects back.

Reproduction

This is in the latest version of chrome. It’s probably important to note that I’m using preact, but I don’t think that’s the issue.

I’m logging in from localhost:8080, and redirecting to localhost:8081.

login url https://dev-id.us.auth0.com/authorize?response_type=token&client_id=dev-key&redirect_uri=http://localhost:8081

redirect image

code index.js

import { Auth0Provider } from "@auth0/auth0-react";

...

const onRedirectCallback = (appState) => {
  history.push(
    appState && appState.returnTo ? appState.returnTo : window.location.pathname
  );
};

const providerConfig = {
  domain: import.meta.env.AUTH0_DOMAIN,
  clientId: import.meta.env.AUTH0_CLIENT_ID,
  redirectUri: window.location.origin,
  onRedirectCallback
}

const About = lazy(() => import('./pages/about/index.jsx'));

export const App = () => {
  return (
    <Auth0Provider {...providerConfig}>
      <LocationProvider>
        <div class="app">
          <Header />
          <ErrorBoundary>
            <Router>
              <Route path="/" component={Home} />
              <Route path="/about" component={About} />
              <Route default component={NotFound} />
            </Router>
          </ErrorBoundary>
        </div>
      </LocationProvider>
    </Auth0Provider>
  );
}

code /home

import { useAuth0 } from "@auth0/auth0-react";

const Home = () => {
  const {
    isLoading,
    isAuthenticated,
    error,
    user,
    loginWithRedirect,
    logout,
  } = useAuth0();

  if (isLoading) {
    return <div>Loading...</div>;
  }

  if (error) {
    return <div>Oops... {error.message}</div>;
  }

  if (isAuthenticated) {
    return (
      <div>
        Hello {user.name}{' '}
        <button onClick={() => logout({ returnTo: window.location.origin })}>
          Log out
        </button>
      </div>
    );
  } else {
    return <button onClick={loginWithRedirect}>Log in</button>;
  }
}

export default Home;

Clicking the loginWithRedirect button here works… it makes me re-authenticate, then redirects back to my app, and it works great. I noticed that the redirect that the js click returns to has the token within the query params, and not the hash fragment. That seems to be the issue.

image

In my case, I’m developing the “marketing pages” with the login button separately from the “app” that gets logged into - hence the different flows. Hopefully that makes sense.

Thanks for your help!

Issue Analytics

  • State:closed
  • Created a year ago
  • Comments:8 (4 by maintainers)

github_iconTop GitHub Comments

1reaction
dudocommented, Oct 6, 2022

Sounds good. Thanks for the explanation!

1reaction
adamjmcgrathcommented, Oct 5, 2022

Forgive me if this is frustrating, for I am not an authentication expert. Thank you for bringing me up to speed!

It’s no problem

At the end of the day… both the href and the js are just calling a url with some instructions for the callback, no?

Unfortunately not, additional checks need to be stored on the client when making the authorization request and retrieved by the client to verify the authorization response.

In your case, this means that your marketing site must generate some values (including state and a cryptographically generated code challenge and verifier) to include in the authorize url and store on the browser. Then your app needs to access those values and use them to verify the authorization response on your redirect callback page.

These limitations are not unique to this SDK or Auth0, this is just how the protocol works.

What are the levers I need to pull to have parity in their behavior?

I can only recommend the suggestions I’ve already given you:

  • use the SDK to initiate the login from your marketing site (assuming your marketing site and app are on the same domain in your other environments as well)
  • link to the app, then immediately initiate the login from there
Read more comments on GitHub >

github_iconTop Results From Across the Web

URL hash is persisting between redirects
The URL hash (as expected) is never sent to the server, so the server redirect isn't polluted by it, the browsers are just...
Read more >
How to persist URL hash fragments across a login redirect.
Our hash fragment is not part of the URL encoded redirect query paremeter. That's because the hash fragment was never sent to the...
Read more >
The redirect response does not send the hash fragment ...
I am having issues with the Auth0 callback. The problem is that after authentication, the redirect coming back to the browser (Chrome in ......
Read more >
Redirect after login doesn't work with a hash in the URL - Jira
Before redirecting internally to the "next" param, we check if the "next" param url is local, the check assumed that the url fragment...
Read more >
Apache redirect to same path but with a # fragment
However, since #bar is a fragment in the URL above, it seems to get stripped out and cause a redirect loop. I've also...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found