asp.net url and or query string encryption.

[James]

Yes it is if you know where to look for it, what the OP wants is a way to hide/disguise the query string from the user eye if I understand correctly.

I thought it was a general security thing. If it is just hiding what can be seen, that is a fairly narrow minded approach. Kinda like the ostrich burying its head, if they can't see me they can't hurt me.

 

[Raithlin]

it's response.redirect or server.transfer. or am i confusing post and get of form values with something else here ?

Response.Redirect sends the browser a 301:redirect header. Server.Transfer does a server-side redirect, passing on the form variables to the next page.

it's not a matter of "so worried" it's implementing the best practice here. i see however there is another way of passing things between pages by using httpcontext which 'm reading up on with server.transfer VS response.redirect

over point being. i have a login page a user object is created to show that the user is logged in and can do some things;

a) where should that user detail be stored. for example just the ID in a cookie so that can be used to reread any other related info from a sql db.
b) any thing passed via the query string would be better to be encrypted which stops ****oring with it.
c) what would have been the best practice to have a more stream lined and secure page to page implementation over just passing and storing **** around.

Best practice regarding GET vs POST is a general rule that anything that is safe and can be cached uses GET - unsafe and/or uncacheable content uses POST. None is completely safe, which is why encryption is important in many cases. Regarding your login data, the most secure way would be to use expiring once-off keys with every post - but it adds layers of complexity and makes the server work harder - so I wouldn't use this unless I was creating, say, a banking app or something.

Regarding encrypted info - check your input on the server side anyway. I think it doesn't make too much difference either way - I'm assuming only safe info is using GET at this point, and as long as they are both cached on the server it makes no difference. The only thing you gain from encryption is non-SEO and non-user-friendly URLs. The hacker that wants to get in has the tools at his/her disposal to unencrypt most standard encryption algorithms - heck, even I do, if only for debugging.

I generally store user-specific information in the session on the server, and I use basic cookie info to keep a session reference if I need to (and if it is safe to do so). FarligOptredden is right about the application being the place for shared data too - although I see he is very excitable about it.

.asp net is an ongoing thing as i've done way more desktop development and would have wanted to properly know wtf i'm really doing in some areas of implementation and this is why i'm reading and asking.

Glad to hear that you're improving on your current skills. Something all good developers do continually.

 

[FarligOpptreden]

I am very excitable about it... I've learned the hard way that caching data is the only way to improve performance on a server. Also, caching too much (or data that isn't used frequently) adds unnecessary overheads on the server. The same goes for session variables. Making the decision as to what you should store in a session or application cache can become quite daunting when you're working on large-scale applications.

 

[Necuno]

thanks.