How do you debug the WebForms magic that happens in between IIS starting page load and any of your code running?

blakeyrat

Dealing with a large, old, complicated WebForms application here. If WebForms once had some feature or configuration, I can basically guarantee that at some point this application has used it.

My task is to add a couple new Roles to the permissions. Ok; I did that and everything seems to work fine. Except... we have a couple informational pages that are in the WebForms app but only ever called externally. (A single-page JS app creates links to them.)

ON THE TEST SERVER:

If you're logged-in to any of the existing Roles, you can see those pages fine. They load, you can interact, everybody's happy.

If you log into to one of the new Roles I've created, you're magically redirected back to "your" home page in the WebForms app. This is bad; we need the new Roles to behave exactly like the old Roles.

ON MY LOCAL MACHINE, EVEN WHEN USING IDENTICAL CODE TO THE TEST SERVER:

If you're logged on to ANY Role, old or new, you're redirected back to "your" home page if you visit those pages' URL.

So I have two problems I need to fix:

I need to get my local machine behaving like the test server (or at least understand what's different about it)
I need to get my new Roles to behave like the existing Roles when visiting those particular URLs.

The problem is: all this redirecting stuff happens in that mysterious magic land of mystery consisting of all the bullshit WebForms does in between IIS accessing the URL and WebForms actually executing code on your Form.

I have absolutely no idea how to debug this, or even where to look to find out how to debug this. I know code in Global.asax can run on page load, but I don't see anything there that would cause the redirect. If I put a breakpoint on the redirected page, the callstack is blank because it's a 302 redirect so WebForms considers it a "brand new" page load.

Does anybody have any tips/tricks? What other bits of code could be executing before any Page_Load events occur?

locallunatic

@blakeyrat said:

What other bits of code could be executing before any Page_Load events occur?

Are there any Page_Init events or other pre Load events firing? Either one of them is doing something or they aren't being called at all and some other voodoo is going on, but I'm not sure which based on your description.

blakeyrat

@locallunatic said:

Are there any Page_Init events or other pre Load events firing?

How would I tell?

EDIT: how would I even tell which events are pre-Load events?

locallunatic

@blakeyrat said:

how would I even tell which events are pre-Load events?

ASP.NET Page Life Cycle Overview

PreInit
Init
InitComplete
PreLoad

You could try setting them on the page with just a break point in them to catch when they trigger. If the page has a masterpage the ordering between the page's copy of those events and when they trigger on the master (or on a control's copy) can get a bit messy (some trigger on the page first others on the master first).

EDIT: but it's been a while since I've had to do that much mucking about with them so I can't promise anything, but it's where I'd look if I were you.

Maciejasjmj

Have you tried IntelliTrace? I haven't really used it, so I'm not sure how much it can log, but maybe it can give you some idea of what and why's going on.

blakeyrat

Ok, that is actually helpful, thank you.

FOR FUTURE REFERENCE: if you reply to this thread, please provide SPECIFIC information and not vagueness, so I won't inevitably have to ask for clarification. It'll save both of us time.

Updates:

I had previously added a block to Web.Config like this:

<location path="Blah">
    <system.web>
      <authorization>
        <allow roles="Blahs, Foos, Bars"/>
        <deny users="*"/>
      </authorization>
    </system.web>
  </location>

Where the path was set to the path of the page I was trying to open up permissions to. I've found if I revert that change, my local copy starts behaving like the server-- so whatever is doing the redirect for the new Role seems to be completely unrelated to the ASP.Net Authorization configuration. I... guess that narrows it down a bit.

EDIT: If I use one of the existing accounts and check the Page_Load event, there's still absolutely zero callstack to even give me a clue where that goddamned redirect could be happening. I swear they build this stuff to make debugging difficult on purpose. I'm not asking for angels to come down from the heavens and point me to the problem, but a goddamned CALLSTACK would be nice.

blakeyrat

@Maciejasjmj said:

Have you tried IntelliTrace? I haven't really used it, so I'm not sure how much it can log, but maybe it can give you some idea of what and why's going on.

It's apparently not installed in my copy of VS, or those directions are out-of-date.

blakeyrat

EDIT: more information--

When the dumb redirect happens, whatever's doing the redirect first redirects to the application's root level Default.aspx, which then redirects to the user's home URL. So there's another clue...

(Needless to say, there's no callstack on Default.aspx's Page_Load method either.)

Magus

Intellitrace is a standard feature... of nothing less than what used to be premium iirc. Which means that most people don't have it. It might even have been an ultimate only feature like codelens. Things might be a bit better in 2015, but I assume they haven't let you upgrade to that yet.

blakeyrat

Updates:

I found the problem. Remember the XML I posted before?

<location path="Blah">
    <system.web>
      <authorization>
        <allow roles="Blahs, Foos, Bars"/>
        <deny users="*"/>
      </authorization>
    </system.web>
  </location>

Well the XML I actually had was:

<location path="Blah">
    <system.web>
      <authorization>
        <allow roles="Blahs, Foos"/>
        <deny users="*"/>
      </authorization>
    </system.web>
  </location>
<location path="Blah/Foo/Bar">
    <system.web>
      <authorization>
        <allow roles="Blahs, Foos, Bars"/>
        <deny users="*"/>
      </authorization>
    </system.web>
  </location>

It turns out that if Bars can't access /Blah, they also can't access /Blah/Foo/Bar.

So basically this permission system is demented and more specific permissions don't override less specific ones. WTF!?

Now I have to figure out how to solve it...

blakeyrat

Ok so I crafted new XML from scratch. Got it all working, mostly via trial and error. Then I yanked my previous branch and diffed with my current.

The XML is identical. TO THE CHARACTER. Yet now it works and yesterday it did not.

Gremlins, again.

(Actually, now that I think about it, yesterday my local database had gotten corrupted somehow, so the times it wasn't working, I was probably working with a corrupted database. And now it works because I've started from a fresh new database backup.)

dkf

@blakeyrat said:

It turns out that if Bars can't access /Blah, they also can't access /Blah/Foo/Bar.

I'd expect a processing engine to also care about the order of things, using the first matching entry to decide the security policy to apply. Since /Blah matches anything that /Blah/Foo/Bar also matches, if /Blah comes first, it masks the other entry entirely. Which would mean that just swapping the order of the entries would be enough to fix it.

It's possible that that's not what's happening, and that the system usually tries to use the longest match it can and has somehow become confused, but that's rather more complicated than a simple deterministic “use the first match” rule. After all, it's easy enough for a management client to order the rules to get the other behaviour. And I for one would want the actual rule engine to be deterministic when you actually see what the rule system is, as then there's a chance of debugging the silly thing when it doesn't work.