Error : Server has denied you access to this resource.

[vrl-timseo]

Problem

Description:

I have finished the initial installation/configuration by following the steps:

1. I have installed the Magnus plugin from Rock Shop,
2. I have installed the Magnus extension in VS Code,

Then, when I follow the prompts for adding the server, my inputs were:

1. server = https://rock.vrl.church
2. id = tseo
3. pw = (my password)

This adds "rock.vrl.church" in the list of servers, but when I click on it, I get this error
"Server has denied you access to this resource."

These are my settings:

What I expected:

Show me a tree of available directories

What I got instead:

Error message (screenshot attached)

Versions / Details

Thing	Version
Rock Magnus Plugin	Public Beta released October 17, 2022
Required Rock	v13.6
My Current Rock	Rock McKinley 13.7 (1.13.7.1)
SQL Database	Hosted on Azure
VS Code	1.74.0 (Universal)

[jonedmiston]

Question: Is the screenshot above from the computer that's having the issue? If so it appears that the computers current public IP address does not match the rules. If it did there would be a label that noted the rule that matched and the "Add Current IP Address" button would not be displayed. You might try pressing the "Add Current IP Address" and try again.

[vrl-timseo]

Question: Is the screenshot above from the computer that's having the issue? If so it appears that the computers current public IP address does not match the rules. If it did there would be a label that noted the rule that matched and the "Add Current IP Address" button would not be displayed. You might try pressing the "Add Current IP Address" and try again.

Hey @jonedmiston the answer is yes, the screenshots above are from the computer that's having the issue.

However, the third IP Address listed in that screenshot (labeled "VRL Barker - Tim") is the IP Address I added by clicking the "Add Current IP Address" button as you are suggesting (I just relabeled it for the sake of easily recognizing it).

Are you saying that, if the button had worked as it was designed to work, the "Add Current IP Address" button should have become invisible? 🤔

[vrl-kjell]

I tried from home last night as well and received the same message from our sandbox and production. Used the add button which adds the IPV4 address appended with a port number and adding my home IPV6 and IPV4 manually.

One other detail that I'm not sure why it would make a difference: we're hosted on Azure using a web app (not full IIS).

Just thought I'd throw my 2 cents in there.

[jonedmiston]

The intent is for the button not to show if your current IP already matches a rule. The real IP address is not show above. Is the third IP address IP v6? I wasn't aware that the IP v6 segments were separated by periods. I thought they had to be colons.

I would recommend removing the third item and have the tool add it for you via the "Add Current IP Address". Until you see "Matches Rule" the plugin will deny access.

[vrl-kjell]

We've not seen a "matches rule" flag, which is why we can't connect then.

None of the IPs above are v6. Clicking the button adds an IPv4 address with what appears to be a port number after it. I just removed all addresses and and tried again. I added one with our single external IP and then the other is using the add button.

[jonedmiston]

Looks like somehow you're HTTP X-FORWARDED_FOR header has an IP address with a port. I've never seen that before, but it appears to be a thing (rare):
https://serverfault.com/questions/753682/iis-server-farm-with-arr-why-does-http-x-forwarded-for-have-a-port-number

Any idea what in your infrastructure is putting it there (proxy server, CDN)? Could possibly be Azure App Services. We can add code to write around that. Will also have to change that in core.

[vrl-kjell]

Thanks for looking into this with us. I think it's definitely the Azure App Service. It seems to be a common complaint. One of the recommendations I see is to implement an application gateway service using rewrite rules. I haven't that up before.

Any other thoughts? Is there another way to rewrite the http header to drop the port number?

[jonedmiston]

Looking into this more we recently ran into this in another case in core. The method we use to get this value will now remove the colon in v14.1. I'll make a fix in Magnus to work around this before the v1.0 release (soon). I'll keep this open until we add the patch in Magnus.

[jonedmiston]

Since this is fixed in Rock v14.1 we're going to rely on that fix for this issue instead of copying the new code from core to fix it for previous Rock versions (which we'd need to remove in the future). v14.1 is currently in Alpha testing.