Session being overridden between requests?

[mythz]

Don’t think it makes a difference with this but can you change your Services to return a DTOs or a Reference Type. For bool responses you could return an EmptyResponse when it succeeds and throw an error if it fails, or if you don’t want to return a DTO you can return a string, e.g. “true”.

Do you have .NET 5 installed? as it’s required by the dotnet tools. Otherwise I can’t see what’s interfering with ServiceStack Responses from here so would need a small minimal repo I can run locally to repro the issue to be able to investigate further.

[mikkeljohnsen]

Turns out some other nuget source was messing up the installation of x, got it now.

Following your command I get:

I also got the requests from C# -> webservice showing up in fiddler.

Using the IP for the webservice as seen here gets me the same thing:

I got it somewhat working using just http and the webservice IP:

This is the headers from the C# -> webservice request:

and cookies:

[mikkeljohnsen]

Ok so, looking through the requests in fiddler I see that each of these auth requests:

Come with no cookies and get ss-id, ss-pid and ss-opt cookies back:

And then the following requests:

have those cookies set:

But several of these requests happen and they give back new ids everytime:

[mythz]

What’s the BaseURL of your Service? It expects https://localhost:5001/metadata/app.json to exist, if you’re mounting ServiceStack at a different path that needs to included so that {BaseUrl}/metadata/app.json returns a valid response then you can use:

$ x GET {BaseUrl} SwitchToRelative -raw

[mikkeljohnsen]

http://localhost:5051/metadata/app.json Exists:

https://localhost:5001/metadata/app.json does not exist.

[mythz]

So ServiceStack is only hosted on http://localhost:5051? I don’t understand configuration is being used.

Anyway just use http://localhost:5051 if that’s where ServiceStack is configured, try the x tool with a public (i.e. non auth required) Service:

$ x GET http://localhost:5051 PublicRequestDto -raw

[mikkeljohnsen]

Yeah so the set up is an asp.net core application running at https://localhost:5001 and a servicestack webservice running at http://localhost:5051.

On the asp.net core application there’s first a js api from the react app to the .net part and then the .net part communicates with the webservice and hands back the data to react.

I made a new service with no auth required like so:

Which gives me this error:

Using POST I get back:

[mythz]

So it is returning both ss-id/ss-pid Set-Cookie instructions. Was the issue that you were using the wrong URL?

Don’t forget if you’re trying to communicate between different hosts you need to enable CORS, e.g:

Plugins.Add(new CorsFeature(
    allowOriginWhitelist: new[] { "https://localhost:5001" }));

---

Also if you implement Post() for your Service implementation than you need to use the POST HTTP Method, if you use Any() or Get() you can use GET. The behavior is expected.

[mikkeljohnsen]

Before we were looking at the requests from js api to .net where the set-cookies weren’t showing up.

.net to webservice requests weren’t showing up anywhere when I ran the .net application with HTTPS specified in the run/debug config, but do show up now that I just have HTTPS specified in the code and run it with HTTP in the run/debug config.

I do not see allowOriginWhitelist set anywhere but adding the plugin leads to this error: System.ArgumentException: An item with the same key has already been added. Key: Access-Control-Allow-Methods

Access-Control-Allow-Methods I only see at:

Requests are sent using await client.PostAsync<T>(DTO);

[mythz]

Remove the duplicate headers from your HostConfig and add the CorsFeature plugin in your ServiceStack AppHost instead:

Plugins.Add(new CorsFeature(
    allowOriginWhitelist: new[] { "https://localhost:5001" }));

To send cross-domain cookies disable SameSite cookies:

new HostConfig {
     UseSameSiteCookies = false,
     //...
}

[mikkeljohnsen]

That allowed me to set the plugin.

Each auth request is still sending back new ids.

[mythz]

That’s expected if you’re trying to authenticate, try any other Service.

If you need to, you can disable it with:

new AuthFeature {
    GenerateNewSessionCookiesOnAuthentication = false
}

[mikkeljohnsen]

If it’s supposed to send new ids with each auth then doesn’t that explain my problem of the user getting a new session id with every request?

[mythz]

It should only return new Cookies on Authentication, not every request.

The cookies also need to be sent with the Request to not return new cookies, if that’s the issue you need to work out why the request isn’t sending cookies (e.g. SameSite Cookies).

[mikkeljohnsen]

Yep it’s with each auth request but those seem to happen often in our setup:

It does seem like the requests are sending the id cookies with them, it’s just that they get new ids with each auth

[mythz]

Are we still talking about Authenticate requests? Did you disable it GenerateNewSessionCookiesOnAuthentication = false

[mikkeljohnsen]

The auth requests come with no cookies and response with the cookies set:

The requests following that(not auth requests) have the ids and no reponse cookies:

I’m trying to save some data in the session from one request and use it while handling another request, but an auth requests will happen between these and cause new ids to be set so I can’t get the data.

All my services have [Authenticate] on them.

How exactly do I set GenerateNewSessionCookiesOnAuthentication = false? I’m just getting Cannot resolve symbol 'GenerateNewSessionCookiesOnAuthentication' trying to set it.

Nevermind got it set, testing now.

[mikkeljohnsen]

Session key is still changing even with that set.

But in fiddler I do see that each auth request isn’t setting new ids anymore.

[mythz]

How can the session key be changing if it uses the same session id?

[mikkeljohnsen]

Sorry I had to do something before I could finish testing with the new setting.

The auth requests are still giving back new ids every time even with GenerateNewSessionCookiesOnAuthentication = false set, I must have clicked a wrong request earlier.