Problem with special character when using c# api - c#

i have a problem with using character when i want to get user information by using email
the problem is special character in the email
because the api link not supports character for example
this is the Route im using in the api
[Route("api/v1/Users/{Email}")]
and this is the link
api/v1/Users/majed email.com
any special character let the GET not even see the request link
how can i solve this problem ?!

In most scenarios it has been found that a 404 is returned if an email address is sent. The issue is usually caused by the "." in the email address.
If you add a trailing slash it should resolve your issue.
api/v1/Users/majed#email.com/

You could use URL encoded format of the string.
The string majed#email.com would encoded be majed%40email.com.
You can read more at W3 Shools URL Encoding Reference.

Related

Sending an email to outlook with emoji characters using C#

I have a user input on a web page.
They are able to type a message and send.
The message gets sent to them via SMTP and the client they'll be using is outlook.
The problem I am getting is that emoji [😂🐱‍👓🤷‍♂️👍] are coming through as varying amount of ?? question marks.
There's also a number of problematic characters that come through when they paste content from work like special quotes and the em dash which is often substituted in word when people type a dash.
I know outlook supports emoji as I can type them in with Windows + ; and send them fine. But this is getting mangled somehow when I send it through the SMTP client.
Debugging is showing the emoji correctly before sending it through the SMTP client.
Any ideas what I need to do to get it to send without resorting to stripping these characters out? I'd like for people to be able to use these emoji if they like.
Thanks to #Steve for making me reconsider the obvious 🙌
Turns out all I needed to do was set the BodyEncoding to System.Text.Encoding.UTF8 on the message.
Setting the IsBodyHtml property to true was not enough.
Not sure what the default is for this to not work without setting it to UTF8 but oh well.
mail.BodyEncoding = System.Text.Encoding.UTF8;
https://learn.microsoft.com/en-us/dotnet/api/system.net.mail.mailmessage.bodyencoding

Browser converts encoded slash (%2F) to literal slash (/) in path portion of URL

I'm currently working with an email confirmation after registration using ASP.NET Identity.
This library provides a token generation which is needed to complete the registration. This token is used in our application in the following path:
https://localhost/#/account/{token}/setup
And the token is generated by invoking:
var emailToken = _userManager.GenerateEmailConfirmationToken(newUser.Id);
Once I have my token generated, I add it in the path by doing a string.Format this way:
string.Format("https://localhost/#/account/{0}/setup", HttpUtility.UrlEncode(emailToken));
The result looks like this:
https://localhost/#/account/AQAAANCMnd8BFdERjHoAwE%2fCl%2bsBAAAA6gbQhGTTMUWVHDgOwC9T9AAAAAACAAAAAAAQZgAAAAEAACAAAAAqo%2fiAv8iIn7Zox9pS3MOUMVNisAo7Bnada6%2f9wKEe6wAAAAAOgAAAAAIAACAAAABUu7WkD9vHvN2EDz2%2bqGwvJ4j6gj%2f4PaBTbI861jfEcWAAAADJV74LZjKAXv5v1FqYVuWLyTpPBCnLfopSi3rsEEwMHFKwltHL3moL2h%2fvYVs%2fu3LB%2br5Qytuu%2fZYOUWQTY5KzBqHeZoi7RJ02emDI0NTRhIKxfSGGIdbYxuAjsW14G0BAAAAACsC8L%2bdUDzFMgKUOkxWhKofAz8L0mH5VFEt8Oq%2fKYsxIiu4fiA2sGlPfDhhKQnV2lg%2ba8qHydUjqmyfxNex0Pg%3d%3d/setup
but when I open this url in the browser I get:
...and so on!
What I see is that the url is encoded correctly in the body of the email, but is decoded when I open it in the browser by replacing the encoded "%2f" to "/". This leads to an invalid route in my application being that I expect the "/" to be a separator between different resources.
Any thoughts of this behaviour?
References:
Another guy with my problem too
It's probably decoding it because it considers it part of the path.
I would suggest you explicitly treat it as a parameter. That will tell the browser not to decode it. For instance, instead of having this path:
https://localhost/#/account/AQAAANCMnd8BFdERjHoAwE%2fCl%2bsBAAAA6gbQh..........
Use this path:
https://localhost/#/account/?t=AQAAANCMnd8BFdERjHoAwE%2fCl%2bsBAAAA6gbQh......
Notice the addition of ?t= after the end of the account path.
Then consume the t parameter in your application. That will tell the browser that the value at the end is not to be decoded as part of the path but rather preserved in encoded form because it's a parameter.
This would obviously change the path you have (because of the setup part) so adjust accordingly.

Web Api 2 routing issue with special characters in URL

In the middle of developing a Web Api 2 REST service, we have discovered a routing problem. The endpoint is as follows:
.../{email}/...
The problem is that the email could contain special characters such as '+', which results in a 404 resource not found.
We would really like for the user of the service, to be able to specify the email in the URL. But since the email also legally can contain an '&', this can't just be moved to an URL parameter. How would we go about solving this?
Regards
Frederik
UrlEncodeUnicode and UrlDecode should be helpfull in your case.
No, encoding and deconding can only work if yyou're in control of the client and server operations. If otherwise, the best way is to call the endpoint as such
www.yourwebsite.com/api/account/create?email='{email with any characters}'

validate website string c#

I have a form that users enters there website. Problem is some users put their email address in which I do not want. I want a way to check if the url is well structured. e.g. no #, must have a root domain. www subdomains are optional. I am unable to find this anywhere.
I have tried this code
if (!Uri.TryCreate("http://" + websiteurl, UriKind.Absolute, out uri) || null == uri)
returning false on error but my problem is that it still validates without a root domain e.g. I can put in
http://websitename
and validates fine which I do not want. It does return false when I have put in
http://websitename#.
Is there a way I can overcome this problem? also I added
http:// in the passthrough value because the url never validates.
You can use:
Uri.IsWellFormedUriString(inputUrl, UriKind.RelativeOrAbsolute)
Depending on your performance needs, maybe issuing a quick HttpWebRequest for the website url they give and verifying that you get back a success response might be a good option.
You could try with a regular expression.
Uri.IsWellFormattedUriString won't solve the problem here, which includes the ability to distinguish a valid Url from an email address. Both are well formatted Uris.
Use a regular expression. Here's one from the MS forums using C#:
Url validation with Regular Expression
But you should really validate this before it gets sent to the server. If you use the Peter Blum validators, he's already done the work for you.
Peter Blum's Validators
Or if you want to put in your own JavaScript file, check out this StackOverflow thread.
Url Validation using jQuery

What is the correct encoding for querystrings?

I am trying to send a request to an url like this "http://mysite.dk/tværs?test=æ" from an asp.net application, and I am having trouble getting the querystring to encode correctly. Or maybe the querystring is encoded correctly, the service I am connecting to just doesn't understand it correctly.
I have tried to send the request with different browsers and logging how they encode the request with Wireshark, and I get these results:
Firefox: http://mysite.dk/tv%C3%A6rs?test=%E6
Ie8: http://mysite.dk/tv%C3%A6rs?test=\xe6
Curl: http://mysite.dk/tv\xe6rs?test=\xe6
Both Firefox, IE and Curl receive the correct results from the service. Note that they encode the danish special character 'æ' differently in the querystring.
When I send the request from my asp.net application using HttpWebRequest, the URL gets encoded this way:
http://mysite.dk/tv%C3%A6rs?test=%C3%A6
It encodes the querystring the same way as the path part of the url. The remote service does not understand this encoding, so I don't get a correct answer.
For the record, 'æ' (U+00E6) is %E6 in ISO-LATIN-1, and %C3%A6 in UTF-8.
I could change the remote service to accept the UTF-8 encoded querystring, but then the service would stop working in browsers and I am not really interested in that. Is there a way to specify to .NET that it shouldn't encode querystrings with UTF-8?
I am creating the webrequest like this:
var req = WebRequest.Create("http://mysite.dk/tværs?test=æ") as HttpWebRequest;
But the problem seems to originate from System.Uri which is apparently used inside WebRequest.Create:
var uri = new Uri("http://mysite.dk/tværs?test=æ");
// now uri.AbsolutePath == "http://mysite.dk/tv%C3%A6rs?test=%C3%A6"
It looks like you're applying UrlEncode over the entire URL - this isn't correct, paths and query strings are encoded differently as you've seen. What is doing the encoding of the URI, WebRequest?
You could manually build the various parts using a UriBuilder, or manually encode using UrlPathEncode for the path and UrlEncode for the query string names and values.
Edit:
If the problem lies in the path, rather than the query string you could try turning on IRI support, via web.config
<configuration>
<uri>
<iriParsing enabled="true" />
</uri>
</configuration>
That should then leave international characters alone in the path.
Have you tried the UrlEncode?
http://msdn.microsoft.com/en-us/library/zttxte6w.aspx
I ended up changing my remote webservice to expect the querystring to be UTF-8 encoded. It solves my immediate problem, the webservice can not be correctly called by both PHP and the .NET framework.
However, the behavior is now strange in browsers. Copy pasting an url like "http://mysite.dk/tv%C3%A6rs?test=%C3%A6" into the browser and then pressing return works, it even corrects the encoded characters and displays the location as "http://mysite.dk/tværs?test=æ". If then reload the page (F5) it still works. But if I click on the location bar and press return again, the querystring will become encoded with latin-1 and fail.
For anyone interested here is an old Firefox bugreport about the problem: https://bugzilla.mozilla.org/show_bug.cgi?id=284474 (thanks to #dtb)
So, it seems there is no good solution.
Thanks to everyone who helped though!

Categories