Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I have been searching for some best practice guidance when using the QueryString in ASP.NET and haven't really found any.
I have found a helpful optimization article: http://dotnetperls.com/querystring
But I am more interested in answering the following questions:
Case rules? All lowercase? Pascal Case? Camel Case?
My personal preference is all lowercase, but consistency is most important.
Avoiding special characters in parameter names?
Should parameters and values be obfuscated for security purposes?
etc...
Any more guidelines would be appreciated!
Whatever is in your query string is viewable and changeable by the end user. This means they have the potential to change it to view or access data they shouldn't, or to influence the behavior of your site/app. So it goes without saying that you trust nothing on the query string, and check everything before you use it. When you check it, don't check for things that are wrong with it (that could be an infinite list), instead check for things that are correct. If even one of your checks fails then you should discard the query string data, or treat it as suspect. If you have encrypted or encoded the data on the query string it can still have unintended side effects if the user messes with it and you blindly trust it, even if the user's changes were nonsensical due to the encoding.
The one approach I take with storing sensitive data in the query string is to not do it; instead I will store the sensitive data server side (in the Session, Cache or a table in the database), and then I will have a randomly generated key (usually a GUID) in the query string to identify it, so the URL would look like this:
http://myurl.com/myPage.aspx?secretKey=73FA4A5A85A44C75ABB5E323569628D3
It is rather difficult to brute force a GUID and the chances of a GUID collision are infinitesimally small, so if the end user messes with the query string then they end up getting nothing.
This approach also works well when I need to store many things and the querystring starts to become too long - the data needing to be tracked can be kept in an object which is then stored in Session or Cache, and once again a GUID is used as its key.
My 5 cents:
if you have a page that can be called by other people, like
http://myurl.com/myPage.aspx?secretKey=73FA4A5A85A44C75ABB5E323569628D3
then you don't want them to experience problems when they misspell the K in secretKey by not making it a capital letter.
So here my rules:
Do it all lowercase. Never uppercase, because there are some small letters that don't have a corresponding uppercase letter such as the German double s.
QueryString["mykey"].ToLower().Equals("73FA4A5A85A44C75ABB5E323569628D3")
is a bad idea, because QueryString["mykey"] might be NULL (Exception NULL reference).
No complicated things like if string.IsNullOrEmpty() if else if object.equals(querykey, "comparison"). Simply use StringComparer.OrdinalIgnoreCase.Equals(key, "73FA4A5A85A44C75ABB5E323569628D3"), this works on NULL, returns false, no additional null/emtpy check needed.
I think there is no better answer between slugster and Stefan. Best to do both referring to guids and using lower case, so the example above would actually read http://myurl.com/mypage.aspx?secretkey=73fa4a5a85a44c75abb5e323569628d3
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Last week, I had to create a little GUI for homework.
None of my school mates did it. They have stolen my one from where we had to upload it and then they uploaded it again as theirs. When I told my teacher it was all my work he did not believe me.
So I thought of putting a useless method or something inside with a proof that I coded it. I thought of encryption. My best idea up till now:
String key = ("ZGV2ZWxvcGVkIGJ5IFdhckdvZE5U"); //My proof in base64
Can you think of some other better ways?
I had the same problem as you a long time ago. We had Windows 2000 machines and uploaded files to a Novel network folder that everyone could see. I used several tricks to beat even the best thieves: whitespace watermarking; metadata watermarking; unusual characters; trusted timestamping; modus operandi. Here's them in order.
Whitespace watermarking:
This is my original contribution to watermarking. I needed an invisible watermark that worked in text files. The trick I came up with was to put in a specific pattern of whitespace between programming statements (or paragraphs). The file looked the same to them: some programming statements and line breaks. Selecting the text carefully would show the whitespace. Each empty line would contain a certain number of spaces that's obviously not random or accidental. (eg 17) In practice, this method did the work for me because they couldn't figure out what I was embedding in the documents.
Metadata watermarking
This is where you change the file's metadata to contain information. You can embed your name, a hash, etc. in unseen parts of a file, especially EXE's. In NT days, Alternate Data Streams were popular.
Unusual characters
I'll throw this one in just for kicks. An old IRC impersonation trick was to make a name with letters that look similar to another person's name. You can use this in watermarking. The Character Map in Windows will give you many unusual characters that look similar to, but aren't, a letter or number you might use in your source code. These showing up in a specific spot in someone else's work can't be accidental.
Trusted Timestamping
In a nutshell, you send a file (or its hash) to a third party who then appends a timestamp to it and signs it with a private key. Anyone wanting proof of when you created a document can go to the trusted third party, often a website, to verify your proof of creation time. These have been used in court cases for intellectual property disputes so they are a very strong form of evidence. They're the standard way to accomplish the proof you're seeking. (I included the others first b/c they're easy, they're more fun and will probably work.)
This Wikipedia article might help your instructor understand your evidence and the external links section has many providers, including free ones. I'd run test files through free ones for a few days before using them for something important.
Modus operandi
So, you did something and you now have proof right? No, the students can still say you stole the idea from them or some other nonsense. My fix for this was to, in private, establish one or more of my methods with my instructor. I tell the instructor to look for the whitespace, look for certain symbols, etc. but to never tell the others what the watermark was. If the instructor will agree to keep your simple techniques secret, they will probably continue to work fine. If not, there's always trusted timestamping. ;)
If your classmates stole your code from the upload site, I would encrypt your homework and email the key to the teacher. You can do this with PGP if you want to be complicated, or something as simple as a Zip file with a password.
EDIT:
PGP would allow you to encrypt/sign without revealing your key, but you can't beat the shear simplicity of a Zip file with a password, so just pick a new key every homework assignment. Beauty in simplicity :)
If you are giving source code to the teacher, then simply add a serialVersionUID to one of your class files that is an encrypted version of your name. You can decrypt it to the teacher yourself.
That does not mean anything to the others, just for you. You can say it's a generated code, if they're stealing it, probably won't bother to modify it at all.
If you want to do it in a stylish way, you could use this trick, if you find the random seed that produces your name. :) That would be your number then, and wherever it appears that would prove that it was you who made that code.
This happened with a pair of my students who lived in the same apartment. One stole the source code from a disk left in a desk drawer.
The thief slightly modified the stolen source, so that it wouldn't be obvious. I noticed the similarity of the code anyway, and examined the source in an editor. Some of the lines had extra spaces at the ends. Each student's source had the same number of extra spaces.
You could exploit this to encode information without making it visible. You could encode your initials or your student ID at the ends of some lines, with spaces.
A thief will likely make cosmetic changes to the visible code, but may miss the non-visible characters.
EDIT:
Thinking about this a little more, you could use spaces and tabs as Morse-code dits and dahs, and put your name at the end of multiple lines. A thief could remove, reorder or retype some lines without destroying your identification.
EDIT 2:
"Whitespace steganography" is the term for concealing messages in whitespace. Googling it reveals this open-source implementation dating back to the '90s, using Huffman encoding instead of Morse code.
It seems like an IT administration problem to me. Each student should have there own upload area which cannot accessed by other students.
The teacher would be a higher level up, being able to access each student upload folder. If this is not possible go with #exabrial answer as that is the simpliest solution.
The best thing you can do is to just zip the source code with a password and e-mail the password to the teacher.
Problem solved.
Use a distributed (=standalone) version control system, like git. Might be useful too.
A version history with your name, and dates might be sufficiently convincing.
What was stolen ?
The source ? You can put random Strings in it (but it can be changed). You can also try to add a special behavior know only from you (a special keypress will change a color row), you can then ask to the teacher "the others know this special combo ?". Best way will be to crash the program if a empty useless file is not present in the archive after 5 minutes of activity, your school mates will be too lazy to wait this ammount of time.
The binary ? Just comparing the checksum of each .class will be enough (your school mates are too lazy to rewrite the class files)
Just post your solution at the last minute. This won't give time to anyone to copy it.
And send a feedback to the administrator to disallow students to see other students assignments.
If you upload the file in a .zip with password encryption, anyone can just crack the password by downloading the .zip file and have their cpu run a million queries at it if they are that big of a cheat thief. Unfortunately, some are and it's easy to do.
Your source can be viewed on the shared server by the other students. The teacher should really be giving you your own password encrypted directory to upload to. This could be done easily just by adding subdomains. But perhaps the teacher might allow you to upload the files to your own server for him to access them there.
It's also possible to obfuscate the script so that it has a document.write('This page was written by xxxxx'), forcing anyone who copies your work to not be able to remove the credit unless they first decrypt it. But the real answer is that your school needs to give each of its students their own password protected directories.
In my case, my teachers came with a better approach. The questions they provided has something to do with our registration number.
Ex:
Input to a function/theory is our Registration number, which is
different for each student
So, answers or the approach to the solution are relatively different from each student.This make the necessarily of all students has to do their homework on their own, or at-least get to know how to hack the approach with their own registration[it may be harder than learning the lession ;)].
Hope your lecturer will read this thread before his next tutorial :D
It appears that SQLite, apparently as a "compatibility feature", parses double quoted identifiers as string literals if no matching column is found.
I understand that it does so for people who write improper sql, and for backwards compatibility with legacy projects created by such people, but it makes debugging very difficult for those of us writing proper sql on brand new projects.
For example,
SELECT * FROM "users" WHERE "usernme" = 'joe';
returns a query with 0 rows, since the string 'usernme' does not equal the string 'joe'.
This leaves me scratching my head wondering why i'm not getting joe's row even when i know there's a user by that name until I painstakingly backtrack my code and realize that I left out an a.
Is there any "strict mode" PRAGMA or API option to enforce quoting rules and treat all double-quoted strings as identifiers so that it will inform me immediately if one is misspelled?
(And please, no answers telling me not to quote identifiers if I don't need to, because any such answer is basically telling me that in order to get proper debugging, you have to write bad code in the first place.)
This is hardcoded in the SQLite parser and cannot be changed from the outside.
I also asked in the SQLite channel and someone there was kind enough to look through the source code and create a patch, and even started a thread on the mailing list describing the patch:
http://www.mail-archive.com/sqlite-users#sqlite.org/msg73832.html
It's not an answer that works for the official builds, but it may be someday. For the moment, I'm just going to recompile it myself with this patch.
Ten years later, and this doesn't completely meet your criteria about "strict mode" kinds of things, but here's a trick I used to make some queries safer, if you can remember to use it. It's to give your table an alias and reference it:
SELECT t."nosuch_column" FROM some_table t;
I suppose in this form, it's clear to SQLite that a literal isn't desired.
When accessing a form or query string value from code-behind in ASP.NET, what are the pros and cons of using, say:
// short way
string p = Request["param"];
instead of:
// long way
string p = Request.QueryString["param"]; // if it's in the query string or
string p = Request.Form["param"]; // for posted form values
I've thought about this many times, and come up with:
Short way:
Shorter (more readable, easier for newbies to remember, etc)
Long way:
No problems if there are a form value and query string value with same name (though that's not usually an issue)
Someone reading the code later knows whether to look in URLs or form elements to find the source of the data (probably the most important point)
.
So what other advantages/disadvantages are there to each approach?
the param collection includes all (4) collections:
Query-string parameters
Form fields
Cookies
Server variables
you can debate that searching in the combined collection is slower than looking into a specific one, but it is negligible to make a difference
The long way is better because:
It makes it easier (when reading the code later) to find where the value is coming from (improving readability)
It's marginally faster (though this usually isn't significant, and only applies to first access)
In ASP.NET (as well as the equivalent concept in PHP), I always use what you are calling the "long form." I do so out of the principle that I want to know exactly from where my input values are coming, so that I am ensuring that they get to my application the way I expect. So, it's for input validation and security that I prefer the longer way. Plus, as you suggest, I think the maintainability is worth a few extra keystrokes.
I'm building a form and I wonder if there is a significant advantage in showing values in a more human readable format; e.g:
index.php?user=ted&location=newyork
Rather than:
index.php?user=23423&location=34645
On the one hand, having the query string a little more readable allows the user and search engines to better understand where they are, but this also creates a little more work on the server side, as I'll have to track down the associated rows through something other than their unique id.
For example, first find what the id of 'newyork' is before being able to work on other rows that require the location_id. I always prefer to give the db as little work as possible.
Edit: decided to go with readability. I figure I can always use the mysql query cache to speed things up if necessary.
Use human readable values when you can. Just be sure to sanitise the input.
Edit: Yes, this can and should still be done for SEO purposes (if its worth it to you) if you have lots of choices. Even if the user has lots of choices, you should know what they are (or what the limits are) so that you can properly sanitise the input. For instance, if they are choosing states, you can know all 50. If they are just making up their own text, make sure on your end that its only text.
A good rule of thumb is to store data as id's and display it as human readable text etc.
Depends on your goals.
If you are talking about something like a blog where you want everyone to see everthing (and find it easily), then the human/search engine readable format is a no brainer.
If these pages are locked behind a login then it doesn't much matter. You can do what is easier on the database.
For most internet apps, I'd err to the side of readability since that will help with search engines as well.
You shouldn't worry about the efficiency for any typically sized application on any reasonable database engine. Write your app for users, not for query optimizers. QO's can more easily take care of themselves. Deal with optimization in the unlikely event you start seeing a problem.
I am going to come from a different direction. In my opinion a URL should be readable if want the user to be able to use the URL to change their parameters by editing the URL instead of using the UI. An example would be https://www.coolreportingapp.com/accountReport.jsp?account=ABC&month=200911 . In this example, the user can "easily" change the account or month they looking at without messing with the UI. This of course means you need to validate the URL params each and every time, which you should do anyway. If you don't want the user to alter the URL params, you need to obfuscate and hash values and use the hash to verify they haven't.
Seriously, IMHO, in your example, none is more readable than the other. Do normal users know that "&" is a separator from "variables" in "user=ted&location=newyork&"? Do they need to know that exists something like a variable? Having this in mind, what's the difference in showing numbers or words?
If you really want readable urls you should build SEO Friendly urls (human readable). Remember that even a "dashes vs underscores" simple question matters in the end.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
At my job, I have to implement web forms for loan applications with sometimes up to a hundred different input fields, and then save the application into the database for later retrieval.
The person whom I replaced created a sql table with 100s of columns where each row represents a loan application and there is a column for every field.
The problem with this is that I find myself having to type out the 100 fields a bunch of times, getting data from form, saving to database, retrieving from database, writing to output webform.
And then whenever there is a change to the application, I have to make the change in quite a few places.
So it can not only be cumbersome but error prone.
Is there a good design pattern that handles this?
See if you can come up with a better table design. 100 Cols is just too much IMO. If not you could use dynamic data. Also look for a better UI pattern or break it into more than 1 pages, looking at 100 fields to fill in could be over whelming for the users.
Code generation is the best bet. MyGeneration and CodeSmith are two very good tools.
I've had very similar projects and I used both generation tools and prefer CodeSmith.
100's of fields in a form is too many. Try to aim for max 20 per page.
If you can, try to isolate each part of this form into a separate page, and even better, into a wizard of some kind.
e.g. (example steps)
Step 1: Client Profile (name, age, SSN, etc.)
Step 2: Loan Data (Fixed, Variable, Amount, Terms, Special Deals...)
Step 3: Credit Check?, Pre-Approval?
Step 4: Variations/Calculations...
If you organize the data in structured groups, you should be able to make each portion work independently (e.g. you can input basic loan data, and get some preliminary numbers without needing to enter client data (yet).
More importantly, if the user enters a value in one of the 100 fields that causes the backend to not store (e.g. value out of range) what happens? does the user lose all the data they entered? - for usability make sure that nothing is lost when the user attempts to save/move to the next step.
Perhaps ASP.NET Dynamic Data would work for you. It is described as "a framework that enables you to quickly build a functional data-driven application"
I've worked with these loan applications before and I'll tell you straight out that your data model is broken. Are you gonna make a new row in the BigTable when a borrower comes in for a refi? What if the deal falls through but they want to try again for a different house? If you just edit the data in the row for that application then you're losing valuable metrics on your % of closed deals.
First, fix your data model. Then, embrace LINQ if at all possible.
With respect to the UI, I'd either do it as a wizard (which is pretty close to how these apps are filled out) or build it as one big form that the user scrolls through and adds stuff to (use AJAX in each section so that the user can save as they go along).
You also need to consider off the shelf solutions for this stuff. Don't reinvent the wheel here; these loan apps don't change often enough to throw a full time developer at them.
Edit: Sorry I was assuming that this was for residential mortgages. I don't know if that's true, but I still think your data model is broken. If you have the ability to change it you should.
Design pattern? But of course: The Adaptive Object-Model.
One thing that you can do is programmatically take the column names and put them on a file in the format you need. That will be to solve your immediate pain. Below is a piece of c# code that will get the column name from a oledbreader object.
internal List<string> GetFieldList(string sTableName)
{
tableName = sTableName;
BuildQuery("*");
command = SetupConnection();
List<string> FieldList = new List<string>();
OleDbDataReader reader = command.ExecuteReader();
for (int i = 0; i < reader.FieldCount; i++)
FieldList.Add(reader.GetName(i).ToString());
return FieldList;
}
To solve the situation in the long run, you probably want to do store procedures or functions with the fields as parameteres. you still have to put the values in each of the parameters, but is going to easy the management of each
he problem with this is that I find myself having to type out the 100 fields a bunch of times, getting data from form, saving to database, retrieving from database, writing to output webform.
hope it helps!!!
Ouch.
Is LINQ available to you? What version of .NET are we talking about here?
BTW, if it isn't obvious already, from a GUI perspective I suggest you hide most of these fields from the end user and reveal them in sections as the user progresses, which has the advantage that you can avoid showing what doesn't need to be and validate as you go.
And with some sort of progress indicator so they know there's an end in site (ha ha).
I've had issues like this before, and know there may be valid reasons for having so many columns. It's rare, but it can happen.
What you might want to do, is create a partial class in it's own file which contains all the data field code. This might be fields, properties, and possibly method parameters, and/or just your CRUD functionality. And generate that partial class, this will help ease your future maintanence.
Good Luck.