Welcome to the world of web apps. There are a few ways to handle this situation, but the way I normally do it is to validate each of these instances in the code-behind before showing the data and continue using querystrings. I figure it's the safest way. If somebody is tampering with a querystring then it just bounces them back to where they came from.

>I'm writing an Asp.Net WebForms app where I am calling an edit page an passing in the data about the record to be edited using query string parameters in the URL.
>
>Like:
>
> http://myapp.path/QuoteItemEdit.aspx?PK=1234&DeviceType=12&Mode=Edit
>
>On a previous page in the app, I have presented the user with a GridView of screened items he can edit based on his account privileges, and I call the edit page with these above parameter list, and the page know what to do. I do NOT do any additional checking on the target page to validate whether the user has access to the passed in PK record value as I planned to rely on the previous page to filter the list down and I would be fine.
>
>However, it is clear the user can now type in a URL to a different PK and get access to edit that record. (Or, he may have access to Mode=View, but not Mode=Edit or Mode=Delete. Basically, I was hoping to avoid validating the record and access rights on the target page.
>
>I have also tested the same workflow using Session variables to store PK, DeviceType, and Mode before calling the target page, and then reading them from Session in the target page. So there are no query string paramaters involved. This would take control away from the user.
>
>So, I'm looking for feedback on these two approaches so that I choose an accepted/standard way of dealing with this, as it seems like a very common app design pattern for CRUD apps.
>
>
>.