As a Developer, when I sign up to an organisation’s portal I am not being redirected to the API Catalogue on successful sign up.
I would first load the Sign Up page which loads successfully.
I would then fill the form and click on Sign Up. As seen below the Gateway performs a POST to send the form data and it returns 301.
See below the details of the request captured in Firefox’s Network Monitor tool.
The problem is not only about getting a 301 since the user actually gets register but it’s also about that location header not including the host path and therefore after sign up the developer is not redirected to the API Catalogue as it use to be before Tyk 2.0.
Wondering if it could be a problem of the configuration I am sending to the api/portal/configuration
but my guess is that something is not right on the dashboard-api side.
Let me know and I can happily add any information to believe needed to help
We’ve tested the portal, and register works fine (we run 2.0 in our Cloud), and the redirect is part of it, though I’m pretty sure we changed it to a 302.
Have you set the portal options up in your tyk_analytics.conf:
I still haven’t found the solution, think my local environment is not picking up the changes so I need a bit more of investigation from this side. I do believe that your answer should work once I fix my local dev.
Also, Do you know where can I find more detailed documentation about “host_config” and “host_config.portal_root_path” ?
Hey Martin. I am Raul’s colleague and picked this issue up from him.
Our setting for the portal root path in the host config is currently. “portal_root_path”:""
Something that I have tried is setting it to “portal_root_path”: “/portal” and it started to work OK.
However that meant that all our urls now include /portal in the path. Is there anything else that you could suggest please. This issue only is when we hit signup on the registration page. All other pages redirect successfully.
Have you tried to set the portal root path to be “/”?
The templates will try and react accordingly, but may need manual intervention as the default portal install is under /portal usually.
You can always just edit the templates themselves (they are in the /portal folder of the dashboard installation) - if you change the URLs manually then you need to restart the dashboard process so the changes are loaded.
Looks like you are correct, there’s a bug in the redirect. We’ve fixed it in our dev branch and it should be fixed in our automatic build in a few hours (see the nightlies section in our docs). Dev is currently very close to the latest release so is stable.