I am developing a RESTful API for my company, but a couple of people have some issues regarding the exposure of the entity id's, which I can definitely see as a problem regarding securing our data.
My data is scoped, meaning, you cannot see data that doesn't belong to you in the first place.
I am using Web API and EF6.
What have you done about this issue? is this even an issue (why/why not)?
If it is an issue;
Do I encrypt or otherwise obfuscate the id's?
Do I internally map to different id's? - any good frameworks for this?
Do I add a column to all my tables with an uuid and expose that instead?
What is deemed "good practice" or "secure" in this manner?
The edit of this answer seems like a good solution, but I would still like to see what is considered good/bad/great and maybe other solutions to the 'problem'
Not an issue according to this, I can see why it shouldn't be a problem, as long as
The data is securely scoped
"Do I encrypt or otherwise obfuscate the id's?"
If you have to do this then you probably shouldn't be returning them.
"Do I internally map to different id's? - any good frameworks for this?"
This seems like it would add a high level of complication to your app.
"Do I add a column to all my tables with an uuid and expose that instead?"
Some thing to remember when exposing id's is if you have a certain permission to view something at endpoint: /api/user/1 what is to stop you from "walking" the url and changing that to /api/user/2 to view someone else's data. One thing you can do is use Guids as id's to prevent walking the url, but in general if you do not need to return the id's then don't. If you have to return any data at all that is sensitive then it should ALWAYS be over SSL.
I'm pretty inexperienced when it comes to working with IIS, so I apologize if the question is a bit confusing.
In the application, I have a Controller with a method called 'Login' that takes in a string parameter. The parameter identifies the organization the user is trying to authenticate against.
For example:
http://mysite1.com/Login/12345
Visiting this link brings the user to a login page for the organization that is associated with '12345' for their access key.
Is there any way to redirect users that are logging in under '12345' to another server? We have a few beta users that are willing to participate, but the database schemas for both servers are different, so it's important that the beta users are not hitting the wrong site.
After the user logs in, the access key is no longer in the URL, so I can't do matches against it.
I'd like for the user to see the following URL:
http://mysite1.com/Login/12345
http://mysite1.com/Products/
http://mysite1.com/Admin/
While in reality they're on a different server:
http://mysite2.com/Products/
http://mysite2.com/Admin/
I have to emphasize that I really do need the URL to stay 'mysite1' for the user, when in reality they'll be on 'mysite2'. Please let me know if this is possible or not, or if there's a better solution for it.
Sorry if this is a confusing scenario or if there's some information that I'm missing. I'll make edits if necessary.
Virtually anything is possible, but this approach seems really painful.
IIS can perform URL rewriting but it's going to be doing this before it hits the authentication layer so it will not be possible to differentiate users at that level.
It seems like the best option will be to write a custom URL rewriter provider. Looks like this post is attempting to solve it that way.
It really seems better to either redirect to a different server (which I know you're saying you can't do) or merge the multiple versions of functionality into a single app (with different controls/backend models, etc.)
This link may help in understanding a little bit about how the flow works in an ASP.NET MVC app.
Im developing a web application, in which I need to identify a certain page using an identifier.
Usually I would use a auto increment interger, which relates to the ID of the item in the DB.
Like this for example:
http://example.com/item/1
But I see more and more use of identifies like this (TinyUrl and YouTube):
http://example.com/item/1BHYQJh1
And I wonder, should I go for this solution?
What is the benefit, is it just to shorten the ID in case you get up to a really long interger?
Or is it to "hack proof" the soulution so that people cant "guess" the url by replacing 1 with 2.
I really appreciate the last one, I would like to add this extra security to my application. But does anyone know of any code snippets that does this exact thing?
Examples in C# would be great.
This is not really a programming issue, but...
I prefer 'nice' URLs and I am not alone, and to me plain numbers are nicer than 1BHY..., but YMMV.
The 'guessing' you mention is not relevant here. If the user is allowed to access /2 then it doesn't matter. If he is not allowed, then basing the security on obscure URLs is a poor choice. What if someone types the wrong value and stumbles upon page not meant for him.
If you need security, you need to check whether the current user is allowed to access the page at specified URL and act accordingly.
I don't understand what 'examples in C#' mean. These are URLs, they are not expressed in C#.
You could use Guid.NewGuid() to create a 'unique' identifier
Is a GUID unique 100% of the time?
This is the scenario: I have a list of about 5000 URLs which have already been published to various customers. Now, all of these URLs' location has changed on my server side. The server is still the same though. This is a ASP.NET website with .NET3.5/C#.
My requirement is : Though the customers use the older source URL they should be redirected to the new URL without any perceived change or intermediate redirection message etc.
I am trying to make sense of the whole scenario:
Where would I put the actual mapping of Old URL to New URL -- in a database or some config. file or is there a better option?
How would I actual implement a redirect:
Should I write a method with Server.Transfer ot Response.Redirect?
And is there a best practice to it like - placing the actual re-routing in HTTPModules..or is it Application_BeginRequest?
I am looking to achieve with a best-practice compliant methodology and very low performance degradation, if any.
If your application already uses a database then I'd use that. Make the old URL the primary key and lookups should be very fast. I'd personally wrap the whole thing in .NET classes that abstracts it and allow you to create a Dictionary<string,string> of all the URLs which can be loaded into memory from the DB and cached. This will be even faster.
Definitely DON'T use Server.Transfer. Instead you should do a 301 Permanently Moved redirect. This will let search engines know to use the new URL. If you were using NET 4.0 you could use the HttpResponse.RedirectPermanent method. However, in earlier versions you have to set the headers yourself - but this is trivial.
Keep the data in a database, but load into ASP.NET cache to reduce access time.
You definitely want to use HTTPModules. It's the accepted practice, and having recently tried to do it inside Global.asax, I can tell you that unless you want to do only the simplest kind of stuff (i.e. "~/mypage.aspx/3" <-> "~/mypage.aspx?param1=3) it's much more complicated and buggy than it seems.
In fact, I regret even trying to roll my own URL rewriting solution. It's just not worth it if you want something you can depend on. Scott Guthrie has a very good blog post on the subject, and he recommends UrlRewriter.net or UrlRewriting.net as a couple of free, open-source URL rewriting solutions.
Good luck.
The urls on my site can become very long, and its my understanding that urls are transmitted with the http requests. So the idea came to compress the string in the url.
From my searching on the internet, i found suggestions on using short urls and then link that one to the long url. Id prefer to not use this solution because I would have to do a extra database check to convert between long and short url.
That leaves in my head 3 options:
Hashing, I don't think this is a option. If you want a safe hashing algorithm, its going to be long.
Compressing the url string, basically having the server depress the string when when it gets the url parameters.
Changing the url so its not descriptive, this is bad because it would make development harder for me (This is a 1 man project).
Considering the vast amount possible amount of OS/browsers out there, I figured id as if anyone else has tried this or have some clever suggestions.
If it maters the url parameters can reach 100+ chars.
Example:
mysite.com/Reports/Ability.aspx?PlayerID=7737&GuildID=132&AbilityID=1140&EventID=1609&EncounterID=-1&ServerID=17&IsPlayer=True
EDIT:
Let me clarify atm this is NOT breaking the site. Its more about me learning to find a good solution ( Im well aware this is micro optimization, my site is very fast atm ) and making my site even faster ( To challenge myself, and become a better coder ).
There is also a cosmetic issue, I personal think that a URL longer then the address bar looks bad.
You have some conflicting requirements as you want to shorten/compress the url without making it less descriptive. By the very nature of shortening the URL, you will, to a certain extent, make it less descriptive.
As I understand it, your goal is to optimise by sending less over the request. You mention 100+ characters, instead of 1000+ which I assume means they don't get that big? In which case, I'd see this as an unnecessary micro-optimisation.
To add to previous suggestions of using POST, a simple thing would be to just shorten the keys instead of using full names if you don't want to do full url shortening e.g.:
mysite.com/Reports/Ability.aspx?pid=7737&GID=132&AID=1140&EID=1609&EnID=-1&SID=17&IsP=True
These are obviously less descriptive.
But like I said, are you having a real problem with having long URLs?
I'm not sure I understand what's your problem with long URLs? Generally I'd try to avoid them, but if that's necessary then you won't depend on the user remembering it anyway, so why go through all the compressing trouble? Even with a URL of 1000 chars (~2KB) the page request won't be slow.
I would, however, consider using POST instead of GET if possible, to prettify the URL, but that's of course depends on your implementation / environment.
It is recommended a few times here to use POST instead of GET. I would strongly recommend AGAINST picking your HTTP action by what the URL looks like. There is more to this choice than how it is displayed in the browser.
A quick overview:
http://www.w3.org/2001/tag/doc/whenToUseGet.html#checklist
A few options to add to the other answers:
Using a subclassed LinkButton for your navigation. This holds the extra data (PlayerId for example) inside its viewstate as properties. This won't be much help though if you're giving URLs to people via emails.
Use the MVC routing engine to produce slightly improved URLs - no keys for the querystring. e.g. mysite.com/Reports/Ability/7737/132/1140/1609/-1/17/True
Create your own URL shortener like tinyurl.com. Store the url in the database along with each of the querystring values to lookup.
Simply setup some friendly URLs for the most popular reports, for example mysite.com/Reports/JanuaryReport. You can also do this using the MVC routing engine.
The MVC routing engine is stand alone and can work without your site being an MVC site.
With my scheme, one could encode the params section of a URL as a base64 string which is ~50% shorter than a direct base64 representation. So for your case you get:
~50% shorter params section
a base 64 string which hides a lot of the detail
see http://blog.alivate.com.au/packed-url/
Most browsers can handle up 2048 characters in URL; if you don't feel like to use a long parameter list, you can always to pass parameters through POST requests.
There are theoretical problems with extended URLs. The exact limit varies across browser (roughly 2k in sort versions of IE) and server (4-8k in Apache, varying on version and configuration), and isn't officially specified in any RFC that I am aware of.
I would agree with synhershko, and replace the URL with form POST parameters instead if you are concerned that your URLs are growing too long.
I've encountered similar situations in the past, although my reasons for optimisation were for SEO. To me it depends on what you're doing with the page URL variables, are they being appended on all/most pages? If they are then to me there is almost always a much better way, although if you're far down the development path it's probably too late now.
I like being able to 'read' a URL, especially when I drop into an unknown site 2 or more layers deep in the navigation and there site is designed poorly, it's often the easiest and fastest way for an advanced user to find where they are on the site.
If you're interested in it from an SEO point of view, its normally best to have a hierarchy which only contains: / - _
Search engines will try and read URL's, see this video by Matt Cutts (can't remember how far into the video he mentions it but it's a good watch anyway...)
Any form of compression of the URL (hashing, compressing, non-descriptive) is going to:
make the urls harder to read, remember and type in correctly
have a performance impact as you will have to decrypt/decompress/convert the url before you can work with it.
Also, hashing is usually considered to be non-reversible - given a hashed value you shouldn't be able to work out what generated it, but you could use it to look up a value in a database, which gets you back to your first issue of short-long lookups.
You could easily just remove the redundant "ID" at the end of each parameter, and possibly strip out vowels or similar to "shorten" the url without losing too much from the semantics of the request.
But to be honest, the length of your URL is one of the least things to worry about in terms of performance - look at the size of any cookies you're sending back and forth between the browser and the server, and the page size you're sending back.