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

Edited 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.

__Impact__:
Low as there is a workaround. But the experience is bad due to no easy way of figuring out assembly loading failure due to 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.



Edited Feature: Add tracing for filter overrides [1106]

$
0
0
IOverrideFilter doesn't have any behavior itself; it is used as a marker for the filter pipeline processing, so the tracer for the filter itself doesn't output anything (since there are no methods on this filter interface).

Adding tracing to FilterGrouping would allow showing the effect of filter overrides in the trace output.

Edited Task: Trace more information from authentication filter tracers [1110]

$
0
0
The current implementation of authentication filter tracers is fairly minimal. A more complete implementation would log factors such as when a filter short-circuits or sets a principal.

Commented Unassigned: EmailAddressAttribute does not allow empty strings [1112]

$
0
0
I have an MVC4 application and I've decorated a string property with the EmailAddress attribute, but not the Required attribute:

```
[EmailAddress]
string EmailAddress { get; set; }

```

My View uses TextBoxFor to expose the property for editing:

```
@Html.LabelFor(model => model.EmailAddress)
@Html.TextBoxFor(model => model.EmailAddress)
@Html.ValidationMessageFor(model => model.EmailAddress)
```

When I submit the form for processing with an empty string (i.e., left the field in the view blank), it returns to the view, indicating the email address is not valid in the validation message.

Looking at the source code here, the problem seems obvious:

```
public override bool IsValid(object value)
{
if (value == null)
{
return true;
}

string valueAsString = value as string;
return valueAsString != null && _regex.Match(valueAsString).Length > 0;
}
```

I'd love it if that last line was:
```
return !string.IsNullOrEmpty(valueAsString) && _regex.Match(valueAsString).Length > 0;
```

I understand that the empty string is, technically, not a valid email address, but then either is null, and you've taken the time to check for that (twice!). IMHO, it seems more suitable to rely on the Required attribute for checking that a property "has value", and use the other attributes to validate the value meets another requirement.
Comments: When fixing, we need to add an parameter to EmailAddressAttribute for allowing empty email. By default we should keep the old behavior to avoid breaking changes

Edited Issue: EmailAddressAttribute does not allow empty strings [1112]

$
0
0
I have an MVC4 application and I've decorated a string property with the EmailAddress attribute, but not the Required attribute:

```
[EmailAddress]
string EmailAddress { get; set; }

```

My View uses TextBoxFor to expose the property for editing:

```
@Html.LabelFor(model => model.EmailAddress)
@Html.TextBoxFor(model => model.EmailAddress)
@Html.ValidationMessageFor(model => model.EmailAddress)
```

When I submit the form for processing with an empty string (i.e., left the field in the view blank), it returns to the view, indicating the email address is not valid in the validation message.

Looking at the source code here, the problem seems obvious:

```
public override bool IsValid(object value)
{
if (value == null)
{
return true;
}

string valueAsString = value as string;
return valueAsString != null && _regex.Match(valueAsString).Length > 0;
}
```

I'd love it if that last line was:
```
return !string.IsNullOrEmpty(valueAsString) && _regex.Match(valueAsString).Length > 0;
```

I understand that the empty string is, technically, not a valid email address, but then either is null, and you've taken the time to check for that (twice!). IMHO, it seems more suitable to rely on the Required attribute for checking that a property "has value", and use the other attributes to validate the value meets another requirement.

Edited Unassigned: Provide request message extension for getting client IP address [1116]

$
0
0
__Scenario__:
Users would like to log the IP address of the remote client making the request.

__Issue__:
Its not easily discoverable as to how to retrieve the value. Users would first try to check the current HttpRequestMessage instance for any presence of this, but it does not have this detail. Also if you look at the workaround, the user has to handle different ways for all the hosts to retrieve the data.

__Impact__:
Low. User experience is effected. But this question has come up many times now in Stackoverflow.
* http://stackoverflow.com/questions/17364801/how-to-get-ipaddress-and-useragent-in-asp-net-web-api-get-methods/17365027?noredirect=1#comment25212229_17365027
* http://stackoverflow.com/questions/15712720/get-web-api-consumer-ip-address-and-hostname-in-asp-net-c-sharp
* http://stackoverflow.com/questions/9565889/get-the-ip-address-of-the-remote-host

__Workaround__:
```
private string GetClientIp(HttpRequestMessage request)
{
// OWIN Self host
IDictionary<string, object> owinEnvProperties = request.Properties["MS_OwinEnvironment"] as IDictionary<string, object>;
if(owinEnvProperties != null)
{
return owinEnvProperties["server.RemoteIpAddress"].ToString();
}
// Web Host
if (request.Properties.ContainsKey("MS_HttpContext"))
{
return ((HttpContextWrapper)request.Properties["MS_HttpContext"]).Request.UserHostAddress;
}
// WCF Self Host
else if (request.Properties.ContainsKey(RemoteEndpointMessageProperty.Name))
{
RemoteEndpointMessageProperty prop;
prop = (RemoteEndpointMessageProperty)this.Request.Properties[RemoteEndpointMessageProperty.Name];
return prop.Address;
}
else
{
return null;
}
}
```

Created Unassigned: Add support for matrix parameters at help page. [1122]

$
0
0
Since it is not guaranteed that query parameters are being cached, matrix parameters should be used where applicable. But currently the help page doesn't shows up these possible requests. Our team decided to use standard query parameters in URIs only for sorting and paging and other non filtering actions on resources. For filtering we want to use matrix parameters.

Example:

```
/// <summary>
/// Get customers
/// </summary>
/// <param name="name">Name of the customer.</param>
/// <param name="surname">Surname of the customer.</param>
/// <returns>Returns a list of customers.</returns>
[Get("api/customers;name={name};surname={surname}")]
public IEnumerable<Customer> GetByFilter(string name, string surname)
{
...
}
```

Instead of:
```
/// <summary>
/// Get customers
/// </summary>
/// <param name="name">Name of the customer.</param>
/// <param name="surname">Surname of the customer.</param>
/// <returns>Returns a list of customers.</returns>
[Get("api/customers?name={name?}&surname={surname?}")]
public IEnumerable<Customer> GetByFilter(string name, string surname)
{
...
}
```

Kind regards,
Andy

Edited Unassigned: Add support for matrix parameters at help page. [1122]

$
0
0
Since it is not guaranteed that query parameters are being cached, matrix parameters should be used where applicable. But when using matrix parameters the help page wont show these requests. Our team decided to use standard query parameters in URIs only for sorting and paging and other non filtering actions on resources. For filtering we want to use matrix parameters.

Example:

```
/// <summary>
/// Get customers
/// </summary>
/// <param name="name">Name of the customer.</param>
/// <param name="surname">Surname of the customer.</param>
/// <returns>Returns a list of customers.</returns>
[Get("api/customers;name={name};surname={surname}")]
public IEnumerable<Customer> GetByFilter(string name, string surname)
{
...
}
```

Instead of:
```
/// <summary>
/// Get customers
/// </summary>
/// <param name="name">Name of the customer.</param>
/// <param name="surname">Surname of the customer.</param>
/// <returns>Returns a list of customers.</returns>
[Get("api/customers?name={name?}&surname={surname?}")]
public IEnumerable<Customer> GetByFilter(string name, string surname)
{
...
}
```

Kind regards,
Andy

Edited Unassigned: Add support for matrix parameters at help page. [1122]

$
0
0
Our team decided to use standard query parameters in URIs only for sorting and paging and other non filtering actions on resources. For filtering we want to use matrix parameters.
Since it is not guaranteed that query parameters are being cached, matrix parameters should be used where applicable. But when using matrix parameters the help page wont show these requests.

Example:

```
/// <summary>
/// Get customers
/// </summary>
/// <param name="name">Name of the customer.</param>
/// <param name="surname">Surname of the customer.</param>
/// <returns>Returns a list of customers.</returns>
[Get("api/customers;name={name};surname={surname}")]
public IEnumerable<Customer> GetByFilter(string name, string surname)
{
...
}
```

Instead of:
```
/// <summary>
/// Get customers
/// </summary>
/// <param name="name">Name of the customer.</param>
/// <param name="surname">Surname of the customer.</param>
/// <returns>Returns a list of customers.</returns>
[Get("api/customers?name={name?}&surname={surname?}")]
public IEnumerable<Customer> GetByFilter(string name, string surname)
{
...
}
```

Kind regards,
Andy

Edited Unassigned: Methods with matrix parameters are not shown in help page [1122]

$
0
0
Our team decided to use standard query parameters in URIs only for sorting and paging and other non filtering actions on resources. For filtering we want to use matrix parameters.
Since it is not guaranteed that query parameters are being cached, matrix parameters should be used where applicable. But when using matrix parameters the help page wont show these requests.

Example:

```
/// <summary>
/// Get customers
/// </summary>
/// <param name="name">Name of the customer.</param>
/// <param name="surname">Surname of the customer.</param>
/// <returns>Returns a list of customers.</returns>
[Get("api/customers;name={name};surname={surname}")]
public IEnumerable<Customer> GetByFilter(string name, string surname)
{
...
}
```

Instead of:
```
/// <summary>
/// Get customers
/// </summary>
/// <param name="name">Name of the customer.</param>
/// <param name="surname">Surname of the customer.</param>
/// <returns>Returns a list of customers.</returns>
[Get("api/customers?name={name?}&surname={surname?}")]
public IEnumerable<Customer> GetByFilter(string name, string surname)
{
...
}
```

Kind regards,
Andy

Edited 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()
{
}
}
```

Created Unassigned: Add support for model binding ODataQueryOptions for MVC [1123]

$
0
0
The idea stems from [this](http://stackoverflow.com/questions/17556452/cant-use-odataqueryoptions-with-a-regular-not-webapi-controller-derived-cla) SO question. It would be useful to support ODataQueryOptions<T> with MVC too.

Edited Feature: Please readd FormatterContext [221]

$
0
0
Hello there,

today I updated to the RC version of the WebAPI and found that there was no real workable replacement for the FormatterContext.

Beside I have no idea why it had to be removed there are various reasons in my opinion as to why it should be there. As long as there is no other alternative to access some kind of request based context.

Perhaps a little information about our current setup will help to show about why we need it.
To support some kind of Versioning we decided to create a version based MimeType (ContentType). So that we can have special formatters for each version we support. This of course would still be possible without a context, but during the mapping of the objects to those versioned data transfer objects we enrich our response with various other information, for example with information we get from our SAP backend system. Now the problem is that the SAP Connector does only work if a HttpContext is available (Bad programming from their side but nothing we could change). With the FormatterContext I was at least able to get the HttpContext and set it for the current thread which will execute the SAP request. But of course this is not possible anymore now without such a context.

Also depending on the HttpLanguage Header the mapping engine used the Context to localize the response, which is again not possible as the Mapping Engine itself has no access to the HttpHeaders directly and relied on an existing Context to access.

At least for the later problem the workaround with the GetPerRequestFormatterInstance works as at least until now no localized object need to be deserialized.

With best regards,
Kay

Commented Issue: Exceptions in DefaultODataPathHandler result in 500 [909]

$
0
0
ODataExceptions in DefaultODataPathHandler mean that the incoming request is incorrect or not supported. These should result in 404 or 400 rather than a 500.

For now, a workaround would be to have a custom path handler that looks like this,
```
public class CustomPathHandler : DefaultODataPathHandler
{
public override ODataPath Parse(IEdmModel model, string odataPath)
{
try
{
return base.Parse(model, odataPath);
}
catch (ODataException e)
{
return null;
}
}
}
```
Comments: Fixed to send back a 404: http://aspnetwebstack.codeplex.com/SourceControl/changeset/010712b9a95ba344b67e7bba5fa05789a51ef417

Edited Issue: Exceptions in DefaultODataPathHandler result in 500 [909]

$
0
0
ODataExceptions in DefaultODataPathHandler mean that the incoming request is incorrect or not supported. These should result in 404 or 400 rather than a 500.

For now, a workaround would be to have a custom path handler that looks like this,
```
public class CustomPathHandler : DefaultODataPathHandler
{
public override ODataPath Parse(IEdmModel model, string odataPath)
{
try
{
return base.Parse(model, odataPath);
}
catch (ODataException e)
{
return null;
}
}
}
```

Edited Task: MQ: Upgrade TeamCity to latest version [814]

Closed Task: MQ: Upgrade TeamCity to latest version [814]

$
0
0
Just like the title says
Comments: Upgraded to 8.0

Edited Task: MQ: Upgrade TeamCity to latest version [814]

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.

Commented 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.
Comments: Fixed in master 712.0 main build
Viewing all 7215 articles
Browse latest View live


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