I have a simple problem for that I'd like to hear your thoughts:
I have this URL in Rails http://example.com/hosts/show/somehost
I'm getting the 'somehost' part via params[:id]. I'm calling URI.encode on 'somehost' but this does not encode '.' characters. Rails won't recognize ID parts with points in it so I tried to replace the points with '%2E' - That works, but Firefox (and I guess other browsers too) changes the '%2E' back to points right after the request. This makes copy&paste impossible and will lead to a lot of problems.
I'd like to encrypt and decrypt the 'somehost' part in an URL-safe way - Any suggestions? I can't call by an numeric primary key because of the underlying architecture. I have to look up by name.
Thank you all very much!
You could use base64 encoding, but it would be better to fix the actual problem you are having. This issue is described here. You need to set a :requirements key for your routes file with a regex that includes the dot.
Related
I am working with 3rd party integrations which require encoding my payload to base64 format. I am using Rails to do this
Base64.encode64("No way") # output: "Tm8gd2F5\n"
Most of the 3rd parties I've worked with do not have any problem with this, however, a few do have problems decoding the encoded value with \n. After facing the issue, I found another version of base64 encoding called strict_encode64
Base64.strict_encode64("No way") # output: "Tm8gd2F5"
which solves the problem.
I am wondering why \n is added to the encoded string.
encode64 uses Array#pack under the hood. It uses the 'm' directive which according to the docs has the rather obscure note "if count is 0, no line feed are added, see RFC 4648". Taking a punt, the reverse might be true - if the count > 0 then add a new line. I've looked through RFC 4648 and can't find any mention of this, but I'm guessing it must in there somewhere.
Sorry if none of that helps. Went down the rabbit hole on this, but maybe there are some crumbs in there that are useful.
Edit: seems that Python also does this and it appears to be deliberate (is specified in their unit tests). So this looks even more like it's related to RFC 4648 (or maybe RFC 2045), but I can't for the life of me find any mention of it in either RFC.
In my view I'm displaying the link in a such way:
<%= #casino.play_now_link %>
So, #casino.play_now_link can be like this: https://www.spinstation.com/?page=blockedcountry&content=1 What I need, is to display only this part: www.spinstation.com. I tried gsub('http://', '').gsub('https://', ''), and it works, but how can I remove the part of url name after .com? Thanks in advance.
Don't use regexes at all for this sort of thing, use URI from the standard library:
URI.parse(#casino.play_now_link).hostname
or, for a more robust solution, use Addressable:
Addressable::URI.parse(#casino.play_now_link).hostname
Of course, this assumes that you've properly validated that your play_now_links are valid URIs. If you haven't then you can add validations that use URI or Addressable to do so and either clean up existing play_now_links that aren't valid URIs or wrap the parsing and hostname extraction in a method (which is a good idea anyway) with some error handling.
In a simple way one can use
.split('/')[2]
which is regex based and depends on the '/' in your url.
But as #mu is too short mentioned: URI is better for this.
I have some easy to read URLs for finding data that belongs to a collection of record IDs that are using a comma as a delimiter.
Example:
http://www.example.com/find:1%2C2%2C3%2C4%2C5
I want to know if I change the delimiter from a comma to a period. Since periods are not a special character in a URL. That means it won't have to be encoded.
Example:
http://www.example.com/find:1.2.3.4.5
Are there any browsers (Firefox, Chrome, IE, etc) that will have a problem with that URL?
There are some related questions here on SO, but none that specific say it's a good or bad practice.
To me, that looks like a resource with an odd query string format.
If I understand correctly this would be equal to something like:
http://www.example.com/find?id=1&id=2&id=3&id=4&id=5
Since your filter is acting like a multi-select (IDs instead of search fields), that would be my guess at a standard equivalent.
Browsers should not have any issues with it, as long as the application's route mechanism handles it properly. And as long as you are not building that query-like thing with an HTML form (in which case you would need JS or some rewrites, ew!).
May I ask why not use a more standard URL and querystring? Perhaps something that includes element class (/reports/search?name=...), just to know what is being queried by find. Just curious, I knows sometimes standards don't apply.
I have developed a ASP.NET MVC application. I have a conroller with the name EmployeeController and it got a method called GetEmployeeByName. GetEmployeeByName() takes a name of type string as parameter.
So When I send a request like this, i get the data back :
someDomain:9999/Employee/GetEmployeeByName/Roger Federer
But if the name contains an '&' (you & me), I get a '400 Bad Request' as response from server.
someDomain:9999/Employee/GetEmployeeByName/you%20&%20me
Even if i encode it dont get a reposne back
someDomain:9999/Employee/GetEmployeeByName/you%20&%20me
What is the right way to encode such (data with special character) data?
What is the right way to encode such (data with special character) data?
The right way is to use a query string parameter and not be putting those things as part of the uri portion. Read the following blog post from Scott Hansleman. I will only quote hos conclusion:
After ALL this effort to get crazy stuff in the Request Path, it's
worth mentioning that simply keeping the values as a part of the Query
String (remember WAY back at the beginning of this post?) is easier,
cleaner, more flexible, and more secure.
As you can see in the blog post there are some hacky ways to make it work and circumvent IIS handling but it simply is not something that I would recommend you venturing into. Just put this name in the query string.
I've seen that IIS has a problem with letting colons into URLs. I also saw the suggestions others offered here.
With the site I'm working on, I want to be able to pass titles of movies, books, etc., into my URL, colon included, like this:
mysite.com/Movie/Bob:The Return
This would be consumed by my MovieController, for example, as a string and used further down the line.
I realize that a colon is not ideal. Does anyone have any other suggestions? As poor as it currently is, I'm doing a find-and-replace from all colons (:) to another character, then a backwards replace when I want to consume it on the Controller end.
I resolved this issue by adding this to my web.config:
<httpRuntime requestPathInvalidCharacters=""/>
This must be within the system.web section.
The default is:
<httpRuntime requestPathInvalidCharacters="<,>,*,%,&,:,\,?"/>
So to only make an exception for the colon it would become
<httpRuntime requestPathInvalidCharacters="<,>,*,%,&,\,?"/>
Read more at: http://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.requestpathinvalidcharacters.aspx
For what I understand the colon character is acceptable as an unencoded character in an URL. I don't know why they added it to the default of the requestPathInvalidCharacters.
Consider URL encoding and decoding your movie titles.
You'd end up with foo.com/bar/Bob%58The%20Return
As an alternative, consider leveraging an HTML helper to remove URL unfriendly characters in URLs (method is URLFriendly()). The SEO benefits between a colon and a placeholder (e.g. a dash) would likely be negligable.
One of the biggest worries with your approach is that the movie name isn't always going to be unique (e.g. "The Italian Job"). Also what about other ilegal characters (e.g. brackets etc).
It might be a good idea to use an id number in the url to locate the movie in your database. You could still include a url friendly copy of movie name in your url, but you wouldn't need to worry about getting back to the original title with all the illegal characters in it.
A good example is the url to this page. You can see that removing the title of the page still works:
ASP.NET MVC Colon in URL
ASP.NET MVC Colon in URL
Colon is a reserved and invalid character in an URI according to the RFC 3986. So don't do something that violates the specification. You need to either URL encode it or use another character. And here's a nice blog post you might take a look at.
The simplest way is to use System.Web.HttpUtility.UrlEncode() when building the url
and System.Web.HttpUtility.UrlDecode when interpreting the results coming back. You would also have problems with the space character if you don't encode the value first.