I have this strange behavior. Have you seen this before?
I go to /ui and login. Everything’s OK.
Then I click one of the QueryXXX and click the ship icon to go to Locode.
Then I’m logged out. Every time I switch between Locode and API Explorer.
I notice this call which fails:
https://…/auth?callback=loadAuth&jsconfig=eccn
I’ve noticed lately that /auth seems to have changed name to /api/Authenticate. Could this be it?
v6.8.1 of SS and NET 6.0.
No, check cookies between requests, make sure it remains the same. Check the console and Web Inspector for any warnings.
It’s the same service, i.e. /auth is the user defined route for the Authenticate service which is accessible from the /api/Authenticate JSON API route that service clients use.
The only warning I can see in the console is:
https://<hostname>/auth?callback=loadAuth&jsconfig=eccn net::ERR_ABORTED 404
(I filtered the hostname for this forum)
Cookies are standard, but I notice that they are cleared after the 404. This is how it looks after logged in, but before switching between /ui and /locode.
Are you sure it’s returning 404? That API should return 401 if the user is not authenticated.
What happens if you try to open the URL in a browser?
I agree, a 401 would be more what I expected if the actual service got called. The previous error was from the Network tab from within the browser though. Here’s calling it directly:
I’ll see if I can provoke this error from a new fresh x new install. That would be easier to debug for everyone.
Just to show that the server’s up and running on the same URL (yes, I had to blur the URL but it’s the same):
I didn’t login since yesterday, so that’s why it’s timed out I guess.
Last piece of information.
After the previous screenshot showing I’m logged out, I did login via Locode, then called it again, getting info that I’m logged in (on this: /api/Authenticate?callback=loadAuth&jsconfig=eccn via Chrome URL bar).
Then I went back to Locode and did the switch to ApiExplorer, showing that I’m logged out (due to the 404), then immediately got back to the tab with the /api/Authenticate, reload, still logged in.
I’ve tried to make an example, but in the example, there’re no problems. So I’ll compare line-by-line to see what can have gone wrong with my real code.
This is the example, by the way:
x new web-tailwind
x mix auth
Added [Authenticated] to Hello service, to provoke Log In
x mix auth-memory
Uncommented the CreateUser example line to have an example user.
x mix autoquery
x mix sqlite
Created type “Test”
Added
using (var db = appHost.Resolve<IDbConnectionFactory>().Open())
{
db.CreateTableIfNotExists<Test>();
}
in the Configure.Db.cs’s ConfigureAppHost()
But in this case, the URL https://localhost:5001/auth?callback=loadAuth&jsconfig=eccn has absolutely no problems.
I’ll proceed and update once I find the culprit.
As suspected, the error is on my side. Read on for interesting(?) info:
To find it, I used SourceGear’s free DiffMerge. Since the Configure.XX.cs have identical names across ServiceStack projects, it was quick to find the problem.
The problem was this line:
authFeature.ServiceRoutes = new Dictionary<Type, string[]> {
{typeof(AuthenticateService), new[] { "/api/auth", "/api/auth/{provider}" }},
};
Previously I had tried to put all my API’s behind an /api route. I followed some advice on some older forum posts, and added the above, in addition to this:
//// put all routes behind /api path
//public override RouteAttribute[] GetRouteAttributes(Type requestType)
//{
// var routes = base.GetRouteAttributes(requestType);
// routes.Each(x => x.Path = "/api" + x.Path);
// return routes;
//}
which you can see I removed again. Just forgot to remove the first one.
So: no bug in SS just in my code
About serving under a path*
To host my services behind a path, I’d just use the rewrite functionality in the web server instead (incoming and outgoing), as well as informing SS using HandlerFactoryPath in the code.
I can mention that (as mentioned in another post), the links inside /ui and /locode (for switching between them) are using /, which could be fixed like this I think (tested by modifying in the browser/debugger (in my head I classify this as something SS should fix)
