I have two aspx pages in my sharepoint portal like "NewRequest.aspx" and "EditRequest.aspx" and both have their respective visual webparts. Now there is a third webpart on homepage which contains all the requests and on clicking of the request the requestID should be passed to "EditRequest.aspx" to fetch the request for editing.

I dont want to use querystring as user can pass value by modifying the url. Is there any better approach to achieve this?

3 Answers
3

I think you shouldn't consider passing the RequestID through the Querystring as a "worse" solution or as a less "proffesional" one. After all, Sharepoint does it out of the box.

Yes, there are other possibilities. For example, you could put the ID in a session variable, but session is disabled on Sharepoint by default. And if you have multiple Web Front Ends, you have to make sure somehow, that every subsequent request from the same user will read the same session (either using sticky sessions, either distributed session).

You could also put the variable in the server cache, but if using the default ASP.NET cache, you have the same restraints as above regarding multiple WFE.

You could use GUIDs as IDs in the QueryString, to prevent users from trying out all sorts of IDs, because it's much harder to guess valid GUIDs than guessing valid integers. But why are you affraid that users might change that ID from the QueryString? Authorization reasons? It shouldn't be "security by obscurity" which prevents them accessing unauthorized data. It should be real security trimming.

Could you tell me please more about the reason why you would like to avoid passing the ID in the QueryString?

Norbert guessing the item ID like itemid=2 or itemid=3 is easy..but i guess i need to check the user id along with item id also in the editrequest.aspx code..humm..i have only 1 wfe by the way.
–
user342944Dec 9 '12 at 18:07

If it's data from Sharepoint (meaning a list, document library, etc) it's doing the security trimming automatically for you. Meaning that users who don't have access to that list, will receive an access denied. Anyway, you have the current user in the SPContext.Current object, so there is no need to pass the user's ID in the QueryString. And regarding the WFEs: maybe you have one now, but what if in 1 year somebody will decide to go for two or three WFEs? Will you tell them, sorry, no, we can't do that because my code will not work on more than one?
–
NorbertDec 9 '12 at 18:39

you are right. I am looking for encrypting and decrypting my query string instead of clear text...
–
user342944Dec 9 '12 at 19:46

Ok, it seems a pretty good choice to me, if you want to avoid sending query string parameters in clear text. :-) Congrats.
–
NorbertDec 10 '12 at 6:24