[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

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

Chris,

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

0

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

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

0

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

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

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

0

Have you tried hitting alt+enter?

0

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

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

0

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

0

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.