Quantcast
Channel: ASPNETWebStack Issue Tracker Rss Feed
Viewing all 7215 articles
Browse latest View live

Edited Unassigned: Exception inside PushStreamContent won't be caught by ExceptionFilterAttribute? [1089]

$
0
0
Hi,

I'm using PushStreamContent in asp.net web api to stream data to the client, I have derived from ExceptionFilterAttribute to capture all the exceptions and return standard HttpError to client. However,
I found that exception thrown inside PushStreamContent won't be caught by ExceptionFilterAttribute, it will return a "text/html" error message to client.
Below is the sample code:

response.Content = new PushStreamContent(
async (outputStream, httpContent, transportContext) =>
{
try
{
// do something and throw exception here

}
catch (Exception ex)
{
throw;
}
finally
{
outputStream.Close();
}
});

Edited Issue: Allow to pass an empty ModelState into CreateErrorResponse [1091]

$
0
0
Would be nice if ```CreateErrorResponse(HttpStatusCode.BadRequest, ModelState)``` didn't throw an exception in case ModelState is empty.

Edited Issue: Make EntitySetConfiguration ctor public [1093]

$
0
0
The constructors in EntitySetConfiguration are public, while the constructors in EntitySetConfiguration<T> are internal. The constructors in EntitySetConfiguration were made public to ease unit testing, for consistency and for unit testing, please make EntitySetConfiguration<T> constructors also public.

Commented Unassigned: Provide a default implementation for changeset unit of work semantics in OData $batch [1096]

$
0
0
The current implementation of DefaultODataBatchHandler doesn't provide any kind of Unit Of Work semantics as defined for changesets in the OData V3 specification. The current implementation processes the changeset but doesn't perform any kind of rollback operation in case of failure, which is the wrong default behavior.

Provide an abstract method that the user needs to implement in order to provide rollback semantics to be able to use an ODataBatchHandler and provide a default implementation in the DefaultODataBatchHandler that handles the majority of the use cases.

The excerpt from the ODataspec:
> "All operations in a ChangeSet represent a single change unit so a service MUST successfully process and apply all the requests in the ChangeSet or else apply none of them. It is up to the service implementation to define rollback semantics to undo any requests within a ChangeSet that may have been applied before another request in that same ChangeSet failed and thereby honor this all-or-nothing requirement"
Comments: Needs design.

Edited Issue: Direct link generation should be consistent with Url.Link when the OData path is empty and there is a route prefix [793]

$
0
0
The direct link generation generates "http://localhost/prefix/", while Url.Link generates "http://localhost/prefix" when the OData path is empty. There's a slight inconsistency here that we should fix.

Commented Issue: Direct link generation should be consistent with Url.Link when the OData path is empty and there is a route prefix [793]

$
0
0
The direct link generation generates "http://localhost/prefix/", while Url.Link generates "http://localhost/prefix" when the OData path is empty. There's a slight inconsistency here that we should fix.
Comments: Fixed: https://aspnetwebstack.codeplex.com/SourceControl/changeset/694c07e1196d0c20731bb551f11977c8618cdf18

Commented Issue: AuthorizeAttribute can't be overriden [1095]

$
0
0
As the title says, it is currently not possible to override the AuthorizeAttribute set on Controllers with an AuthorizeAttribute set on Actions.
While this is in itself not a bug, it is quite an inconvenience. The attribute would be easier to use if you were able to set it on an Action as well as on the Controller. This would pretty much result in a similar usage process as with the AllowAnonymousAttribute, which can in fact override the Controller level AuthorizeAttribute.

Pseudo-code:
```
[Authorize(Roles = "Administrator")]
public class MyController : ApiController
{
//A hundred (exaggerating here) functions that are limited to Administrators thanks to the AuthorizeAttibute on the Controller.

[Authorize(Roles = "User,Administrator")] //FEATURE: Override only this single action to allow users as well. As it stands now, this is never reached due to the AuthorizeAttribute on the Controller.
public MyObject MyMoreAccesibleAction()
{
}

[AllowAnonymous] //AllowAnonymous can already override the AuthorizeAttribute
public MyObejct MyPublicMethod()
{
}
}
```
Comments: It does not seem to work on my end :/ ``` using System.Web.Http; //AuthorizeAttribute, AllowAnonymousAttribute using System.Web.Http.Filters; //OverrideAuthorizationAttribute [Authorize(Roles = "Administrator")] public class MyObjectController : EntitySetController<MyObject, int> { //Works; Admins only public MyObject DoSomethingForAdmins() { } //Doesn't work. Still Admins only. [OverrideAuthorization] [Authorize(Roles = "User,Administrator")] public MyObject GetSomethingForUsersAndAdmins(int key) { } //Works; everyone can access [AllowAnonymous] public MyObject GetSomethingForEveryone(int key) { } } ``` Using packages 5.0.0-rtm-130619 (Prerelease).

Commented Issue: AuthorizeAttribute can't be overriden [1095]

$
0
0
As the title says, it is currently not possible to override the AuthorizeAttribute set on Controllers with an AuthorizeAttribute set on Actions.
While this is in itself not a bug, it is quite an inconvenience. The attribute would be easier to use if you were able to set it on an Action as well as on the Controller. This would pretty much result in a similar usage process as with the AllowAnonymousAttribute, which can in fact override the Controller level AuthorizeAttribute.

Pseudo-code:
```
[Authorize(Roles = "Administrator")]
public class MyController : ApiController
{
//A hundred (exaggerating here) functions that are limited to Administrators thanks to the AuthorizeAttibute on the Controller.

[Authorize(Roles = "User,Administrator")] //FEATURE: Override only this single action to allow users as well. As it stands now, this is never reached due to the AuthorizeAttribute on the Controller.
public MyObject MyMoreAccesibleAction()
{
}

[AllowAnonymous] //AllowAnonymous can already override the AuthorizeAttribute
public MyObejct MyPublicMethod()
{
}
}
```
Comments: I tried using the same package version (5.0.0-rtm-130619) from our nightly feed, and it was working for me. Full repro source and request/response logs are below. Can you confirm if this sample works for you? Thanks, David __Source Code__ using System; using System.Security.Principal; using System.ServiceModel; using System.Threading; using System.Threading.Tasks; using System.Web.Http; using System.Web.Http.Controllers; using System.Web.Http.Filters; using System.Web.Http.SelfHost; class Program { static void Main() { using (var config = new HttpSelfHostConfiguration("http://localhost:12345/")) { config.HostNameComparisonMode = HostNameComparisonMode.Exact; config.Filters.Add(new SchemeAuthenticationFilter()); config.Routes.MapHttpRoute("Rpc", "{controller}/{action}"); using (HttpSelfHostServer server = new HttpSelfHostServer(config)) { server.OpenAsync().Wait(); Console.WriteLine("Press ENTER to exit . . ."); while (Console.ReadKey().Key != ConsoleKey.Enter) ; server.CloseAsync().Wait(); } } } } public class SchemeAuthenticationFilter : IAuthenticationFilter { public Task<IAuthenticationResult> AuthenticateAsync(HttpAuthenticationContext context, CancellationToken cancellationToken) { IAuthenticationResult result; if (context.Request.Headers.Authorization != null) { result = new SucceededAuthenticationResult(new GenericPrincipal(new GenericIdentity("User"), new string[] { context.Request.Headers.Authorization.Scheme })); } else { result = null; } return Task.FromResult(result); } public Task<IHttpActionResult> ChallengeAsync(HttpActionContext context, IHttpActionResult innerResult, CancellationToken cancellationToken) { return Task.FromResult(innerResult); } public bool AllowMultiple { get { return false; } } } public class MyObject { public string Property { get; set; } } [Authorize(Roles = "Administrator")] public class MyController : ApiController { public MyObject MyNormalAction() { return new MyObject { Property = "AdminOnly" }; } [OverrideAuthorization] [Authorize(Roles = "User,Administrator")] public MyObject MyMoreAccesibleAction() { return new MyObject { Property = "UserOrAdmin" }; } [AllowAnonymous] public MyObject MyPublicMethod() { return new MyObject { Property = "Anonymous" }; } } __Test Results__ POST http://localhost:12345/My/MyNormalAction HTTP/1.1 Host: localhost:12345 Content-Length: 0 HTTP/1.1 401 Unauthorized Content-Length: 61 Content-Type: application/json; charset=utf-8 Server: Microsoft-HTTPAPI/2.0 Date: Fri, 21 Jun 2013 16:22:54 GMT {"Message":"Authorization has been denied for this request."} ------------------------------------------------------------------ POST http://localhost:12345/My/MyNormalAction HTTP/1.1 Host: localhost:12345 Content-Length: 0 Authorization: User HTTP/1.1 401 Unauthorized Content-Length: 61 Content-Type: application/json; charset=utf-8 Server: Microsoft-HTTPAPI/2.0 Date: Fri, 21 Jun 2013 16:22:59 GMT {"Message":"Authorization has been denied for this request."} ------------------------------------------------------------------ POST http://localhost:12345/My/MyNormalAction HTTP/1.1 Host: localhost:12345 Content-Length: 0 Authorization: Administrator HTTP/1.1 200 OK Content-Length: 24 Content-Type: application/json; charset=utf-8 Server: Microsoft-HTTPAPI/2.0 Date: Fri, 21 Jun 2013 16:23:04 GMT {"Property":"AdminOnly"} ------------------------------------------------------------------ POST http://localhost:12345/My/MyMoreAccesibleAction HTTP/1.1 Host: localhost:12345 Content-Length: 0 HTTP/1.1 401 Unauthorized Content-Length: 61 Content-Type: application/json; charset=utf-8 Server: Microsoft-HTTPAPI/2.0 Date: Fri, 21 Jun 2013 16:23:17 GMT {"Message":"Authorization has been denied for this request."} ------------------------------------------------------------------ POST http://localhost:12345/My/MyMoreAccesibleAction HTTP/1.1 Host: localhost:12345 Content-Length: 0 Authorization: User HTTP/1.1 200 OK Content-Length: 26 Content-Type: application/json; charset=utf-8 Server: Microsoft-HTTPAPI/2.0 Date: Fri, 21 Jun 2013 16:23:22 GMT {"Property":"UserOrAdmin"} ------------------------------------------------------------------ POST http://localhost:12345/My/MyMoreAccesibleAction HTTP/1.1 Host: localhost:12345 Content-Length: 0 Authorization: Administrator HTTP/1.1 200 OK Content-Length: 26 Content-Type: application/json; charset=utf-8 Server: Microsoft-HTTPAPI/2.0 Date: Fri, 21 Jun 2013 16:23:27 GMT {"Property":"UserOrAdmin"} ------------------------------------------------------------------ POST http://localhost:12345/My/MyPublicMethod HTTP/1.1 Host: localhost:12345 Content-Length: 0 HTTP/1.1 200 OK Content-Length: 24 Content-Type: application/json; charset=utf-8 Server: Microsoft-HTTPAPI/2.0 Date: Fri, 21 Jun 2013 16:23:41 GMT {"Property":"Anonymous"} ------------------------------------------------------------------ POST http://localhost:12345/My/MyPublicMethod HTTP/1.1 Host: localhost:12345 Content-Length: 0 Authorization: User HTTP/1.1 200 OK Content-Length: 24 Content-Type: application/json; charset=utf-8 Server: Microsoft-HTTPAPI/2.0 Date: Fri, 21 Jun 2013 16:23:46 GMT {"Property":"Anonymous"} ------------------------------------------------------------------ POST http://localhost:12345/My/MyPublicMethod HTTP/1.1 Host: localhost:12345 Content-Length: 0 Authorization: Administrator HTTP/1.1 200 OK Content-Length: 24 Content-Type: application/json; charset=utf-8 Server: Microsoft-HTTPAPI/2.0 Date: Fri, 21 Jun 2013 16:23:50 GMT {"Property":"Anonymous"} ------------------------------------------------------------------

Reopened Issue: Razor V2 Bug:Url Resolution Fails if you have Html Comment with Quotation or Apostrophe [933]

$
0
0
During discussing a thread in ASP.NET MVC forums, found a bug in Razor V2 in which the auto url resolution(~) will not work if you have an html comment with quotation or apostrophe before the url resolution(~) tag. Here is an quick example,
``` Html
<!-- '" -->
<img src="~/images/submit.png" />
```

See this thread,
[http://forums.asp.net/t/1892597.aspx/1?Using+UrlHelper+Content](http://forums.asp.net/t/1892597.aspx/1?Using+UrlHelper+Content)

Edited Issue: Razor V2 Bug:Url Resolution Fails if you have Html Comment with Quotation or Apostrophe [933]

$
0
0
During discussing a thread in ASP.NET MVC forums, found a bug in Razor V2 in which the auto url resolution(~) will not work if you have an html comment with quotation or apostrophe before the url resolution(~) tag. Here is an quick example,
``` Html
<!-- '" -->
<img src="~/images/submit.png" />
```

See this thread,
[http://forums.asp.net/t/1892597.aspx/1?Using+UrlHelper+Content](http://forums.asp.net/t/1892597.aspx/1?Using+UrlHelper+Content)

Commented Issue: Razor V2 Bug:Url Resolution Fails if you have Html Comment with Quotation or Apostrophe [933]

$
0
0
During discussing a thread in ASP.NET MVC forums, found a bug in Razor V2 in which the auto url resolution(~) will not work if you have an html comment with quotation or apostrophe before the url resolution(~) tag. Here is an quick example,
``` Html
<!-- '" -->
<img src="~/images/submit.png" />
```

See this thread,
[http://forums.asp.net/t/1892597.aspx/1?Using+UrlHelper+Content](http://forums.asp.net/t/1892597.aspx/1?Using+UrlHelper+Content)
Comments: @sabellis - Thanks for noting, I reactivated as this was not resolved to the correct duplicate. I did re-verify the workaround here is a sample: @* '" *@ <div>Try this thing out</div> If this example doesn't resolve your issue please let us know in more details what you are trying to do. Note that the @* *@ content is not intended to (and does not) show up in the final markup.

Edited Issue: Razor V2 Bug:Url Resolution Fails if you have Html Comment with Quotation or Apostrophe [933]

$
0
0
During discussing a thread in ASP.NET MVC forums, found a bug in Razor V2 in which the auto url resolution(~) will not work if you have an html comment with quotation or apostrophe before the url resolution(~) tag. Here is an quick example,
``` Html
<!-- '" -->
<img src="~/images/submit.png" />
```

See this thread,
[http://forums.asp.net/t/1892597.aspx/1?Using+UrlHelper+Content](http://forums.asp.net/t/1892597.aspx/1?Using+UrlHelper+Content)

Edited Issue: Redundant type name serialization in OData JSON light minimal metadata mode [984]

$
0
0
When we write the entries for GET http://localhost:50231/Pets/SampleService.Model.BigPet , in JSON light minimal metadata mode, we emit type names for all BigPets. This is redundant as the type of the URI (BigPet) is the same as the type of entry being serialized. We should only emit type names if the entry being written is a derived type of BigPet.

This is happening as we compare the element type of the entity set (in this case, Pet) with the type of the entry being written (in this case, BigPet) and put the type name if they differ. Ideally, we should be checking the type of the uri and not the entity set.

The offending code is in ODataEntityTypeSerializer.cs , method - ShouldSuppressTypeNameSerialization.





Commented Unassigned: Exception inside PushStreamContent won't be caught by ExceptionFilterAttribute? [1089]

$
0
0
Hi,

I'm using PushStreamContent in asp.net web api to stream data to the client, I have derived from ExceptionFilterAttribute to capture all the exceptions and return standard HttpError to client. However,
I found that exception thrown inside PushStreamContent won't be caught by ExceptionFilterAttribute, it will return a "text/html" error message to client.
Below is the sample code:

response.Content = new PushStreamContent(
async (outputStream, httpContent, transportContext) =>
{
try
{
// do something and throw exception here

}
catch (Exception ex)
{
throw;
}
finally
{
outputStream.Close();
}
});
Comments: The best thing that Web API could do here is to Abort the connection. Workaround: Call "HttpContext.Current.Request.Abort()" when an exception occurs to cause the connection to be closed. This way the client would know that a problem has occurred at the service.

Edited Unassigned: Exception inside PushStreamContent won't be caught by ExceptionFilterAttribute? [1089]

$
0
0
Hi,

I'm using PushStreamContent in asp.net web api to stream data to the client, I have derived from ExceptionFilterAttribute to capture all the exceptions and return standard HttpError to client. However,
I found that exception thrown inside PushStreamContent won't be caught by ExceptionFilterAttribute, it will return a "text/html" error message to client.
Below is the sample code:

response.Content = new PushStreamContent(
async (outputStream, httpContent, transportContext) =>
{
try
{
// do something and throw exception here

}
catch (Exception ex)
{
throw;
}
finally
{
outputStream.Close();
}
});

Commented Unassigned: Exception inside PushStreamContent won't be caught by ExceptionFilterAttribute? [1089]

$
0
0
Hi,

I'm using PushStreamContent in asp.net web api to stream data to the client, I have derived from ExceptionFilterAttribute to capture all the exceptions and return standard HttpError to client. However,
I found that exception thrown inside PushStreamContent won't be caught by ExceptionFilterAttribute, it will return a "text/html" error message to client.
Below is the sample code:

response.Content = new PushStreamContent(
async (outputStream, httpContent, transportContext) =>
{
try
{
// do something and throw exception here

}
catch (Exception ex)
{
throw;
}
finally
{
outputStream.Close();
}
});
Comments: We are looking to introduce the behavior kichalla suggests by default.

Edited Issue: Redundant type name serialization in OData JSON light minimal metadata mode [984]

$
0
0
When we write the entries for GET http://localhost:50231/Pets/SampleService.Model.BigPet , in JSON light minimal metadata mode, we emit type names for all BigPets. This is redundant as the type of the URI (BigPet) is the same as the type of entry being serialized. We should only emit type names if the entry being written is a derived type of BigPet.

This is happening as we compare the element type of the entity set (in this case, Pet) with the type of the entry being written (in this case, BigPet) and put the type name if they differ. Ideally, we should be checking the type of the uri and not the entity set.

The offending code is in ODataEntityTypeSerializer.cs , method - ShouldSuppressTypeNameSerialization.





Edited Issue: Redundant type name serialization in OData JSON light minimal metadata mode [984]

$
0
0
When we write the entries for GET http://localhost:50231/Pets/SampleService.Model.BigPet , in JSON light minimal metadata mode, we emit type names for all BigPets. This is redundant as the type of the URI (BigPet) is the same as the type of entry being serialized. We should only emit type names if the entry being written is a derived type of BigPet.

This is happening as we compare the element type of the entity set (in this case, Pet) with the type of the entry being written (in this case, BigPet) and put the type name if they differ. Ideally, we should be checking the type of the uri and not the entity set.

The offending code is in ODataEntityTypeSerializer.cs , method - ShouldSuppressTypeNameSerialization.





Edited Issue: Dictionary model binder throws exception when no values present [373]

$
0
0
This was working fine in MVC 3, I'm not sure if this is an intended change or not.

In MVC4, the model binder cannot properly bind a Dictionary<> if the form was submitted with no values. Consider the following controller action:

[HttpPost]
public void Index(Dictionary<int, bool> values, FormCollection form)
{
}

In MVC3 if this action was called with no values, the dictionary would simply contain 0 entries. In MVC4 if this action is called with no values, it throws an exception: "Specified cast is not valid."

Changing the controller action to the following produces the expected result as it was in MVC3:

[HttpPost]
public void Index(FormCollection form)
{
var values = new Dictionary<int,bool>();
this.UpdateModel(values, "values");
}

I have attached a solution which demonstrates the problem.

Created Unassigned: Upgrade System.Web.Http.SignalR project's SignalR.Core package to the latest. [1102]

$
0
0
__Scenario__:
User would like to use HubController<THub> with Web API. So, the user installs "Microsoft.AspNet.WebApi.SignalR" package.

__Issue__:
The latest publicly released stable version is 1.1.2. After making changes to my ValuesController to inherit from HubController<>, I wasn't able to hit "http://server/api/values". Later I figured out that there were assembly loading failures because of which the controller probing did not find any controllers. This assembly loading failure is due to System.Web.Http.SignalR depending on 1.0.0 whereas I had 1.1.0. This issue is one more scenario for fixing the bug # 1075.

__Workaround__:
Have assembly binding to forward to newer version
```
<dependentAssembly>
<assemblyIdentity name="Microsoft.AspNet.SignalR.Core" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="0.0.0.0-1.0.0.0" newVersion="1.1.0.0" />
</dependentAssembly>
```

__Expected__:

Currently System.Web.Http.SignalR project has the following dependency:
```
<package id="Microsoft.AspNet.SignalR.Core" version="1.0.0" targetFramework="net45" />
```

We need to upgrade it to the latest package.


Viewing all 7215 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>