[2150] Resharper dangerously suggests removing location web.config elements

In a web.config usage of

<location path="does not exist on disk">
    <!--DO NOT REMOVE - this is needed to allow url replacement to redirect user to correct location-->
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
  </location>

Resharper notes that this is an error, and that the solution is to remove this entire element.

Now take in the context of my comment inside my own real usage of the above config. That information is being used by http modules, and by not overriding the default security at this point would fail due to more restrictve default permissions being applied before the request can reach my model or handler.

I don't think you should recommend a user REMOVE a location element. You could leave it as an option further down, but leaving it as the default correction puts this in danger of a user substantially altering their application's security structure without even realizing something changed.

12 comments
Comment actions Permalink

Personally, I think Resharper puts 'remove' as the first item in the quick-fix list too often.

For example, if you create a new type  in the same file as another class (often the quickest way to add it), then the first quick-fix on the new class is 'remove unused', when I'm much more likely to want 'move to file with its own name'.    I guess you could spend forever reordering those lists without agreement though.

0
Comment actions Permalink

Chris,

Makes sense. Would it be enough for you if this suggestion becomes configurable so you'll be able to turn it off?

0
Comment actions Permalink

I think every suggestion of resharper should be an option to switch from error, warning, hint etc.

But what really matters here is the ORDER of operations. Delete for just about anything shouldn't be the top most action, other than probably unused variable maybe a hand full of other specific cases.

0
Comment actions Permalink

Done. As soon as new nightly build happens, you'll be able to configure this warning's behaviour.

0
Comment actions Permalink

I reported elsewhere that it does this when you use a location path to an MVC Area.

Basically, anytime R# cannot find the physical location indicated in the path attribute of a location element, it dims out the entire element. This is pretty stupid, especially when working in MVC, where there is often no correlation between URL and physical path.

0
Comment actions Permalink

Lee,

As soon as new nightly build is available there will be a quickfix to change this highlighting. Try to use it. If it is not convinient still, we'll try some other solution.

0
Comment actions Permalink

I'm on build 2154, still don't see the quickfix that you said would be available.

0
Comment actions Permalink

Have you tried hitting alt+enter?

0
Comment actions Permalink

The quickfix suggests resolving to a physical path. This is exactly what you do NOT want to happen when the location path refers to an MVC Area.

0
Comment actions Permalink

Weird, could you send me a sample for investigation, pls?

0
Comment actions Permalink

Send it where? It's a fairly large project.

0
Comment actions Permalink

I suppose, web.config only would be enough.
You may sent it to me directly to Qx [at] jetbrains [dot] com
or upload to our ftp site: ftp://ftp.intellij.net/.uploads/
Thanks in advance.

0

Please sign in to leave a comment.