This is occurring for me, I have a recent version, if required for investigation then I can upgrade to very latest.
@Darren_Sherwood to help you debug the issue we need a bit more information 
When you click the signup link are you being redirected? are you getting any errors in the DevTools console? are there any errors in your ghost logs? How did you set up your hosting, did you use ghost-cli?
Without some information there’s no way anyone here can help you debug your issue.
@Kevin sorry here are the errors in the DevTools console:
6x Refused to apply style from x, like the following one (I’ve just replaced the-signup-code):
Refused to apply style from ‘Whoops our bad’ because its MIME type (‘text/html’) is not a supported stylesheet MIME type, and strict MIME checking is enabled.
2x refused to execute script as below:
Refused to execute script from ‘Whoops our bad’ because its MIME type (‘text/html’) is not executable, and strict MIME type checking is enabled.
Refused to execute script from ‘Whoops our bad’ because its MIME type (‘text/html’) is not executable, and strict MIME type checking is enabled.
My installation is probably the most supported type, via the digital ocean image. Note hosted via reverse proxy at /blog. Which required a tweak to config via CLI as advised here: Hosting behind reverse proxy - Image and Social share links v>1.0
@Darren_Sherwood this looks like it’s an issue with your server setup rather than Ghost. First you need to work out why your server is not handling your admin URLs correctly, if Ghost was receiving URLs correctly then
https://www.experteasy.com.au/blog/ghost/signup/
would redirect to
https://www.experteasy.com.au/blog/ghost/#/signup/
I think if you fix the above then you should be fine because your root admin URL is 
Whatever it is that’s causing nested paths to be served directly rather than passed to your Ghost instance also seems to be adding the X-Content-Type-Options header which is causing the other errors you’re seeing.
Should I post my nginx config here to see what is wrong with the server setup? I did it via the CLI and did not change anything manually so other people must get the same issue.
The X-Content-Type-Options header could be coming from the parent site that is doing the url rewriting, but why would ghost not work with X-Content-Type-Options set on script and css resources when site security testers usually expect this header to be set? Or put another way, why would you request css and javascript as ‘text/html’?
I did it via the CLI and did not change anything manually so other people must get the same issue.
It’s not the Ghost config that is causing issues here as can be seen by visiting your root admin URL which works fine.
parent site that is doing the url rewriting
This is where your problems are coming from, you need to review how your URL rewriting is working.
Ghost Admin is not being passed through to your Ghost instance properly which is why Ghost isn’t responding with the redirect.
If you post your config for the parent site’s URL rewriting then we might be able to point out what’s wrong.
This is the rewrite from the parent, it is so simple though:
<rule name="Reverse Proxy to blog" stopProcessing="true">
<match url="^blog(.*)" />
<action type="Rewrite" url="https://blog.experteasy.com.au/blog/{R:1}" />
</rule>
Because it is so simple I think I should also post my Nginx config, (if it looks alien, it is a .NET parent site so this is in web.config for IIS rewrite).
It might be more interesting that the following (which is NOT going via the above url rewriting), is giving a 404:
https://blog.experteasy.com.au/blog/ghost/#/signup/
Whereas, the following works fine:
https://blog.experteasy.com.au/blog/ghost/#/signin/
Earlier you said you used the CLI and hadn’t changed anything so I don’t think it’s worth posting unless you have changed something in the nginx config?
That’s expected because there’s no page there, the real URL would be something like Ghost Admin
Can you try adding the trailing slash here so that it’s not repeated when passed through to Ghost? Eg. <match url="^blog\/(.*)" />
Thanks, that fixed it.
For anyone doing the same at some point, of course you’ll want a second rewrite just for the blog-root without a slash.
You may be able to get away with making the slash optional in the regex:
<match url="^blog\/?(.*)" />
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.