I'm creating a site to be available in multiple languages.
What's the best way to do this? Some sites check the browser language setting and redirect to
/english_Version/some/path
My question is, is there a better way? Is the /english_Version/ part necessary or can that be hidden away? What's the best practice here?
The language specific URL is not required, but if you don't use this mechanism, you need some kind of other mechanism to track the user language.
This can be done through cookies, parameters on the URL (other than the directory structure), hidden form fields and other tricks of the trade.
You can also simply look at the browser settings and serve accordingly (without redirection).
However, it is best to give the user a choice in the matter - they might be in a foreign country (think Internet cafe) and want to browse in a different language than that advertised by the browser.
Related
URLs are a user interface, but they are also used to implement the site technically. Compare the following two URLs:
http://example.com/2012/my-article-name/
http://example.com/static/jquery.js
The first is a permalink; part of the "API" if you like. The second is just an addressing mechanism that makes the site work. I might decide to change the second one if I upgrade my site's backend, but I want the first to remain constant for as long as the content at that location exists.
So what are the conventions for indicating that a URL is to be considered part of the site's private technical implementation, rather than part of the public user interface? I've used one above (the word "static"). Another might be an underscore like this:
http://example.com/_/jquery.js
I'm looking for advice, best practice, etc. on this concept.
As far as I know, there is no standard convention for this. And even if there was, I wouldn't bother with it, because:
Who is going to view http://example.com/static/jquery.js?
JavaScript files and "files that make the site work", if you view them, don't display like regular webpages. Users can use that distinction that those files are part of the "technical implementation" of a site.
Visible URL's may be considered part of the user's interface. Just a few years ago, they needed to be unique for every piece of content in the website, or SEO would suffer. Today most search engines support the rel=canonical tag, but still it's a good practice to keep them constant and as logical for the user as possible.
I am playing with learning ASP.NET MVC as a non-web developer. I am trying to find the best idiom to use for an app that has a concept of selecting a 'project' to work on the first page that affects all other pages.
There seems to be three choices:
Just put the information into the session state. Works fine, but isn't very MVC-ish
Embed the state into all URLs ... so instead of /Products/Details/1 the URLs are all /(project_id)/Products/Details/1
Setting a separate cookie for this information
Since nearly all the URLs in the application would require the current project this seems overkill, and makes constructing the URLs used in any of the views that much more work. It would also require that I validate the permissions on each call since the user could easily modify it.
Any suggestions on the best approach -- is using the session such a bad idea?!
Option 2 out of yours is my choice.
So instead of /Products/1/Details
I would make it Project/1/Products/1/Details
Its just more in line with REST. Its virtually irrelevant to MVC, but if you want your Routes and URLs to read like resources in REST, you'll want the url to collapse at the slashes and carry the state. Other ways are to mark a project id in cookie, but that kills linking, so that as someone leaves and comes back they get put back there.
Session also makes it hard to test if you bind yourself directly to that concept.
Personally, I would just use the session. There's nothing non-MVCish about the session really - think of it as just being part of your model.
Using a cookie is really no different than using the session. Embedding it in the URLs is not a bad option though, especially for "linkability" if that's a concern for your project. But it has the side effect of cluttering up URLs and requiring you to pass that ID around constantly from page to page.
What would be a good way to handle URLs on a website that offers multiple languages, but has one primary language (in my case, English).
What should be the address of the home page in English? http://example.com/? http://example.com/en/? http://example.com/english/? Other?
What should be the address of the home page in another language, say, German? http://example.com/german/? http://example.com/de/? http://example.com/deutsch/?
Would the use of language-specific subdomains be appropriate? What would you do and why?
It kind of depends on the structure of your site:
If every language is considered a completely different site, use sub-domains for the language.
This is because different sub-domains is considered different sites by many technologies. Wikipedia does this (http://de.wikipedia.org/) to separate content for different languages entirely.
I wouldn't recommend you to choose this option unless your site is very big.
If every language has its own structure, but is still considered to be versions of the same site, use a top-level "directory" for languages.
For the sake of consistency, I would say that you should also have one for the default language (and omitting it would cause a redirect to the appropriate structure.) I would recommend you to use /en/, /de/, etc. since it's short and concise, and also the standard way of indicating languages.
This is probably your best bet.
If the structure of the site is identical no matter what language it is, and only content on the pages changes depending on the language, you could also consider putting the language modifier as a parameter: /home?lang=en
Google does this, for example: http://www.google.com/search?hl=de&q=foo (they also separate languages by TLD, though.)
Away from the question of how the international URLs should be styled (as that has been covered adequately already)...
One thing that I would personally do is make the site's 'main' domain (i.e. http://example.com) redirect the user appropriately depending on the Accept-Language HTTP header passed by the browser. This is what google.com does, for example.
If you do this, however, make sure that it's possible to switch to another language easily - and save the settings via some other mechanism to allow persistent override (cookies!).
What should be the address of the home page
Would the use of language-specific subdomains be appropriate?
How you like it, doesn't really matter. Design it to be intuitive to the users.
Language names encrypted in URLs won't matter for SEO because nobody will be searching for "en", "de". The names of the products you're offering however will matter very much, because people will be searching for products like "gifts" or "geschenke".
I think that the better stylish solution is to use the address in the format http://yourdomain.com as the home page URL, and identify the localized web pages with ISO 639-1 language codes
As a relative newcomer to both web and MVC, I am looking for a good summary of security best practices that I should implement.
The site will be public facing with "moderately sensitive data" (meaning we can't get sued, but probably wouldn't make many friends if the data got out!) and will have the following security steps taken:
a: Forms/membership authentication and authorization
b: Parameterized queries to prevent sql injection.
c: Automatic timeout with x min of inactivity
c: SSL for client to server encryption
What else do you recommend?
*Securing IIS and the network don't fall under my domain, so I'm more interested in the things I need to do to the software.
If you are using cookies to recognize users, be sure to use an arbitrary token (such as a GUID) to store on the client for identification. I've seen too many websites that store my email address or username in my cookie... just have to change it to another!
Write your software so that it can run under medium trust.
If you are new to web development you should be aware of cross site scripting (XSS). You can use Http.Encode helper method to protect against this in ASP.NET MVC.
Make sure you prevent out of order requests. Ensure client is authenticated before allowing to see sensitive data, or in some cases, make sure the client has come through the correct channel, before allowing a data manipulation. For example, only allow adding an item to your cart if the request came from the product details page. If you don't check, any one can mess around with the action. The URL would be like http://server/cart/add/XYZ123 and anyone could just tweak the 'id' parameter.
Here's another biggie to watch out for: CSRF
http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/
Take a look at this post by Phil Haack- one of the MS dev’s involved in the development.
Additionally take a look at Microsoft Anti-Cross Site Scripting Library to filter out all incoming parameters
Maybe you should choose methods that can be invoke from outside or not. For example be careful make a method like delete any tables like http://yourhost.com/edit/deletealltable.
Make sure you design your class and methods well. And give attributes [NonAction] for preventing public method being invoke.
Make sure you display data (especially sensitive) as you need with minimum fancy design and use client script as long as needed.
Remove any unused trash files like unused files in your solution folder.
Check and double check and validate any input control like textbox. I just can give something in the textbox to hack your system.
If you use mix between MVC and regular ASP.NET, please remove any dependency between them.
Be sure you cover the basics thoroughly, independently of ASP.NET. Make sure your DBMS has a separate user with the minimal required privileges (e.g., CRUD and executing sprocs from specified databases) set up to access the database from the web application. Parameterizing queries is an excellent idea, but ALWAYS SCRUB YOUR INPUT ANYWAY: it is not a complete defense against sql injection.
Keep your design clean and easy to understand. Document whatever you do clearly, especially on the database side. It would be very bad if all your good work were destroyed by two programmers months or years later--one who didn't realize, say, that the database user for the web application (now accessing a database on a different server) shouldn't have root privileges, and another who added a control that didn't cleanse input properly. There's only so much that can be done about this sort of thing, but designing for the possibility that fools will be maintaining your code isn't so that coders will think you're sweet--it's so that fools won't put you out of business.
I have a website where my present "geeky" urls look like:
http://www.bestatdubaiholidays.co.uk/pages/Quote/Details.aspx?GUID=01a25b0c-e0ac-40ba-abd1-298f3abd9612
I want to change these to Search Engine Friendly ones - something like:
http://www.bestatdubaiholidays.co.uk/the-palm-atlantis.aspx
or
http://www.bestatdubaiholidays.co.uk/the-palm-atlantis
I have hundreds of incoming links (from ad campaigns and other sites) to my geeky urls that I want to retain.
So if someone types a geeky url, I want the address bar to show the equivalent search engine friendly url.
Can anyone help? Referring to other articles won't help. Believe me, I've read every one of them. Any example urls will be helpful.
Use something like this http://blog.eworldui.net/post/2008/04/ASPNET-MVC---Legacy-Url-Routing.aspx
You don't have to use MVC, the routing classes are standalone now
I suggest using a Front controller. This means that you use the rewrite engine of whatever httpd server you're using to redirect ALL requests to a single file (index.php or index.aspx or whathaveyou) and then you use code in that file to dispatch to the appropriate page. You can do a redirect from the geeky URLs to the friendly URLs, and if it's a friendly url then you load the appropriate page.
This would be way easier than writing huge rewrite rules for each type of page you might have. And this way all of the work is done in the same language your site is already running, so you don't have to learn and maintain a new file that is in its own language just for the redirection.