Security Exception After Upgrading to 2.6.2
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
NUnit V2 |
Fix Released
|
High
|
Simone Busoli |
Bug Description
From the mailing list, reported by Andy Sipe:
We recently upgraded to 2.6.2 from 2.6.1 and now a few of our top level integration tests are experiencing remoting security exceptions.
In particular we are having this exception thrown when attempting a request:
System.
2.6.1 no problem, 2.6.2 this exception -- no other chnages in the source.
Note that this is occurring in our tests not in the nunit framework directly.
I've included a full stack trace at the end of this message. I'm not sure its going to help a whole lot as it occurs in our test code not in the nunit code. Note that in every case the exception is raised when the response is deserialized and that the actual request works as expected (server gets hit and executes). To me it looks like there is some new security restriction being applied at a somewhat high level that is overriding the defaults.
I was able to work around the issue by setting the type filter and some other security settings in the code that configures the security surrounding remoting. Fortunately we handle all of this outside of configuration files or I'm unsure it would have worked as changing configuration files seemed to have no impact. Once I set the type filter to full everything worked as expected again.
For our purposes this will likely work as we don't use remoting extensively. That said there is like some change in 2.6.2 that may cause others problems as well.
Thanks -andy
at System.
at System.
at System.
at System.
at System.
at System.
at System.
at System.
at System.
at System.
Exception rethrown at [0]:
at System.
at System.
... snip application level frames ....
Changed in nunitv2: | |
status: | New → Confirmed |
assignee: | nobody → Simone Busoli (simone.busoli) |
Changed in nunitv2: | |
milestone: | none → 2.6.3 |
Changed in nunitv2: | |
status: | Fix Committed → Fix Released |
I believe this is actually fixed as a result of another change we just made. Please verify using the preview build I released.