From RPM Wiki
| Table of contents |
Summary
It's a rule that for RPM we never pass data from page to page as URL parameters. The URL will often need to contain delimited IDs and other variables within the Item parameter, however user data in string form is not allowed to be passed. IDs refer to any integer that points to a record in the database. Other variables may include functionality modifiers like a flag to indicate if a page is an edit or a copy. Both IDs and functionality modifiers are acceptable use of the Item parameter.
- OK example: Test.aspx?Item=123!456_1
- Wrong example: Test.aspx?Item=123!AAA%20Networks
- See URL format
Reasons
Manipulation
Data in URLs is very easy to manipulate. On a poorly designed page an unsuspecting user could be given a link from a malicious user with manipulated data to change what is displayed on the screen compared to the actual record that is involved. By only putting pointers to data in the URL, a malicious user can't make deceptive changes since all data on the screen will be loaded from the pointer making any changes obvious.
Revisit
The ID of a record like an agency or a customer never changes. Accessing their information by their ID will always result in the most up-to-date date being displayed. If there is data defined in the URL then that version of the data will be shown again if the saved URL is used again, even if that data is now out-of-date. Every URL is saved in the browser history. The user may save any URL as a bookmark.
In addition to the potential for conflict, there is also the potential data security issue of URLs being saved in plain text format in the browser history. When the URL only contains ID numbers and functionality modifiers then there is no risk.
Nice URLs
RPM is designed to always present the user with a clear URL that is as short as possible. The URL must also be portable so that a user can share a URL with a different user without worrying about data security or user permissions as the security will be applied when the receiving user requests the page and the URL itself contains no data.
Exceptions
Logon
We allow logon by parameter so that users can build logon strings in other applications.
- This technically isn't an exception to our rule anyway, because this is data from an outside system being passed as a parameter, not from an RPM page.
Search
Search strings can be passed in the URL. This is desirable because the data content of the search string is the unique ID of that search.
- In other words, a search for "Test" is always a search for "Test". Changing the string value will change the behavior as expected. There is no potential for conflict.
- It's fine if people bookmark or otherwise revisit a specific search by URL.
- This is not saying a search string must be passed by URL parameter, just that it's fine if it is.
- This page was last modified 15:38, 5 Sep 2008.
- This page has been accessed 427 times.