Hi,
at the moment we have some trouble with SSE but we can’t explain the issue “Access to Subscription ‘. ’ is forbidden” because if we run run our SSE Client C# App with Fiddler as proxy the issue doesn’t occure and we can’t see any differences between the Headers of both requests (with and without Fiddler) do you have some idea regarding this issue?
mythz
July 2, 2019, 8:13am
2
As always for any request issues, please post the raw HTTP Request/Response headers, it’s impossible to identify anything otherwise.
POST /em/event-subscribers/aJJsPE8w8wm8nblysXPs HTTP/1.1
Accept: application/json
User-Agent: ServiceStack .NET Client 5,51
Content-Type: application/json
Host: dave-api-gatew.cloud.ptvgroup.com
Cookie: ss-pid=UrC1tvKds7BDSmqclIRk; ss-id=25KIj1DsXZYGOKjQZKXV
Expect: 100-continue
Accept-Encoding: gzip, deflate
Content-Length: 74
{"Id":"aJJsPE8w8wm8nblysXPs","SubscribeChannels":["aJJsPE8w8wm8nblysXPs"]}
HTTP/1.1 403 Forbidden
Cache-Control: private
Content-Type: application/json; charset=utf-8
Vary: Accept
Server: Microsoft-IIS/8.5
Access-Control-Allow-Origin: *
X-Powered-By: ServiceStack/5.51 Net45/Windows
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, PATCH, OPTIONS
Access-Control-Allow-Headers: Content-Type, X-Requested-With, Authorization
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: *
X-Startup-Errors: 4
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Tue, 02 Jul 2019 06:35:27 GMT
Content-Length: 164
{"responseStatus":{"errorCode":"Forbidden","message":"Access to Subscription 'aJJsPE8w8wm8nblysXPs' is forbidden|fafb9e78-2f21-4c9e-b05f-aa7e006c9df9","errors":[]}}
and the succeeded Fiddler request:
POST /em/event-subscribers/zgKK7iMjrqCbgFDg4e2D HTTP/1.1
Accept: application/json
User-Agent: ServiceStack .NET Client 5,51
Content-Type: application/json
Host: dave-api-gatew.cloud.ptvgroup.com
Cookie: ss-pid=tGjJqpEj3YuQ7n7X36Wg; ss-id=ZlgiTkfdIwUlrbJc5eBG
Expect: 100-continue
Accept-Encoding: gzip, deflate
Content-Length: 74
{"Id":"zgKK7iMjrqCbgFDg4e2D","SubscribeChannels":["zgKK7iMjrqCbgFDg4e2D"]}
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: application/json; charset=utf-8
Vary: Accept
Server: Microsoft-IIS/8.5
Access-Control-Allow-Origin: *
X-Powered-By: ServiceStack/5.51 Net45/Windows
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, PATCH, OPTIONS
Access-Control-Allow-Headers: Content-Type, X-Requested-With, Authorization
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: *
X-Startup-Errors: 4
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Tue, 02 Jul 2019 07:07:53 GMT
Content-Length: 2
{}
mythz
July 2, 2019, 8:25am
5
This is the Exception being thrown:
public object Any(UpdateEventSubscriber request)
{
var subscription = ServerEvents.GetSubscriptionInfo(request.Id);
if (subscription == null)
throw HttpError.NotFound(ErrorMessages.SubscriptionNotExistsFmt.Fmt(request.Id.SafeInput()));
var feature = HostContext.GetPlugin<ServerEventsFeature>();
if (!feature.CanAccessSubscription(base.Request, subscription))
throw HttpError.Forbidden(ErrorMessages.SubscriptionForbiddenFmt.Fmt(request.Id.SafeInput()));
if (request.UnsubscribeChannels != null)
ServerEvents.UnsubscribeFromChannels(subscription.SubscriptionId, request.UnsubscribeChannels);
if (request.SubscribeChannels != null)
ServerEvents.SubscribeToChannels(subscription.SubscriptionId, request.SubscribeChannels);
return new UpdateEventSubscriberResponse();
}
}
Which occurs when a different User Address tries to update its subscription which is different to the original request which created the subscription:
You can use a Request Filter to compare against the current and original User Address.
This validation check can also be disabled with:
Plugins.Add(new ServerEventsFeature {
ValidateUserAddress = false,
});
ok…but why doesn’t the issue occure when using fiddler as proxy?
mythz
July 2, 2019, 9:14am
7
Because the proxy ensures all requests always goes through the same IP?
You want to look at the IP address for the initial SSE request to the /event-stream then compare it with IP of the forbidden response. You can use a network packet sniffer like Wire Shark to view the IP address or add your own diagnostics in a Request Filter as suggested.
Sukram
July 2, 2019, 12:23pm
8
ok thanks…it seems that the configuration
Plugins.Add(new ServerEventsFeature {
ValidateUserAddress = false,
});
solves the issue.