Activities of "rickfrankel"

Hi Musa,

Thanks for the reponse. Give me a few days to digest it and try and reproduce my issue in the original template and not in my complete project.

Thanks

Further to the above. I added in this call just before that check. var test = _roleManager.GetGrantedPermissionsAsync(roleId).Result; if (_roleManager.IsGranted(roleId, permission)) { return true; }

            The test returned permissions, HOWEVER they are not the permissions of that role.  They are the permissions of the role I am logged into as the user creating the new tenant.  
            
            Something doesn't appear to be quite right here.

HI @ismcagdas,

From what I can tell this is failing.

            if (_roleManager.IsGranted(roleId, permission))
            {
                return true;
            }
            

Even though the role does have permissions to the permission this fails. Another piece of info is that I'm using a centralised Redis cache for my caching. When I check the Redis cache I see no entry for the newly created role in the AbpZeroRolePermissions cache key.

I do see an entry in the AbpZeroUserPermissions cache key however. So it looks like when the tenant is being created the role that is just created for the new admin user does not have its permissions cached at the time the SubscribeToAllAvailableNotificationsAsync call is made.

Thanks Rick

Hi @ismcagdas,

        parentPermission.CreateChildPermission(AppPermissions.Pages_Operations_My_Permission_View, L("MyPermission"), featureDependency: new SimpleFeatureDependency(AppFeatures.OneOfMyAppFeaturesFeature), multiTenancySides: MultiTenancySides.Tenant, properties: forUserRoleProperties);

forUserRoleProperties is my own special property I attach to some permissions

it is defined as var forUserRoleProperties = new Dictionary<string, object>() { { "ForUserRole", true } };

The permission itself is a child of this parent permission var parentPermission = pages.CreateChildPermission(AppPermissions.Pages_Operations, L("Operations"), multiTenancySides: MultiTenancySides.Tenant, properties: forUserAndGuestRoleProperties);

This is the only instance I've seen where something strange like this happens. Everwhere else the permissions are rock solid.

Thanks Rick

Thanks Ismcagdas,

Didn't realise it was it's own nuget. Added it in and all good on that front now.

Thanks

Hi All,

Sorry been busy actually release our version 10 upgrade to production over the weekend. All looks finally to be stable so hopefully if Monday goes through smoothly I'll come back in the next day or so with our SignalR details.

Just for reference I am using default mode.

Hey @devinedon,

Undo those changes in the SignalR helper.

What happens is the client code makes a call to https://youapisite/signalr/negotiate?enc_auth_token=bigtokenhere&negotiateVersion=1

This is an API in the the host site that then returns a payload which contains the URL to use. In my case something like this.

{ accessToken: xxxx, availableTransports: [], negotiateVersion: 0, url: "https://myazure.signalr.net/client/etcetcetc }

I assume if you use the network tab in the browser debug tools you are seeing this API return localhost for you.

https://docs.microsoft.com/en-us/azure/azure-signalr/signalr-concept-internals

This negotiate endpoint is exposed by registering the AzureSignalR correctly on the server.

From the looks of your startup.cs it looks to be the same as mine (I'm on V10 so some small differences but have been using Azure SignalR since v7).

I would be confirming that the API project that your front end code is calling is the same host backend that you have your configured startup.cs in. Eg: Somehow you don't have two API hosts running in the backend.

Also confirm in the appsettings.json in your host project that you have "AllowAnonymousSignalRConnection": "true"

Not sure that will make a difference but it does affect the security of the call to the /signalr endpoint.

Hope that gets you in the right direction.

It really does look like something is not registering on the server correctly and thus the negotiate call is not returning the right data.

Can you provide more of the host project startup.cs file.

Assuming you are using the Angular front end. What do you have in your package.json for signalr.

I am using "@microsoft/signalr": "^5.0.1",

Everything just works for me.

Also @ismcagdas is talking about the config files in the angular folder not on the server. They shouldn't matter too much however if you can login correctly.

Hi BitMan,

The issue here is what SignalR backplane are you using? When there are multiple webservers they all need to share a SignalR backplan to be able to communicate correctly with each other.

The way I solved this was switching to an Azure SignalR service which takes care of all the signalr infrastructure for you.

Simply setup an Azure SignalR service and then update the following in your startup.cs of the web.host project.

        services
            .AddSignalR(options => { options.EnableDetailedErrors = true; })
            .AddAzureSignalR(options => options.Endpoints = new ServiceEndpoint[]
            {
                new ServiceEndpoint(_appConfiguration["SignalR:PrimaryConnectionString"], EndpointType.Primary, "Name1"),
                new ServiceEndpoint(_appConfiguration["SignalR:SecondaryConnectionString"], EndpointType.Secondary, "Name2"),
            });

You will have to setup configuration in your appsettings.json.

If you don't want to do that then you'll need to try and put in the Redis or DB based backplanes but websocks still would likely want ARR type connections which is why MS recommend moving away from trying to run SignalR infrastructure yourself.

Cheers