Forgot your password?
Sign in with
Article Help Forum
Submit an article or tip
Import GitHub Project
Import your Blog
Ask a Question
View Unanswered Questions
View All Questions
View C# questions
View C++ questions
View Python questions
View Java questions
All Message Boards...
Running a Business
Sales / Marketing
Collaboration / Beta Testing
Design and Architecture
Internet of Things
C / C++ / MFC
ATL / WTL / STL
Objective-C and Swift
Hardware & Devices
Hosting and Servers
.NET (Core and Framework)
Site Bugs / Suggestions
Spam and Abuse Watch
The Insider Newsletter
The Daily Build Newsletter
Most Valuable Professionals
Where I Am: Member Photos
The Insider News
The Weird & The Wonderful
What is 'CodeProject'?
Ask a Question
Bugs and Suggestions
Article Help Forum
Comments by AlexCode (Top 10 by date)
That's why I spoke about HTTPS. Under HTTPS they won't be able to get the request header because it's encrypted and like this they won't be able to get the session cookie.
But how did he get the valid Admin session token?
- also has the Admin username/pass
- he gained access to the Admin machine
- you're not using https and he found a way to attatch himself to your server router and sniff your requests inspecting the header and so forth
The first 2 you can't do anything about it...
The 3rd I think you might have bigger problems if someone can actually do this easily in your organization.
Reason for my vote of 1 \n And I forgo the one that has been around for a long time that is super fast JSON.net
Unless you're doing this as a school project I would advise you to stop loosing time with it and use one of these 3 tools.
Reason for my vote of 3 \n Why?
"...generally shows that while developing there is too much load on the page using the viewstate and this method works best for us"
How much do you actually save out of viewstate with this?
Looks more maintenance overhead than actually improvement... What am I missing here?
Reason for my vote of 2 \n I don't think this is a good idea.
At the end you can go back but you should't be able to perform any action, so no harm can be done.
All the 3 "most common problems" you pointed should be prevented in the backend code, not by disabling the browser Back-Button.
In fact, users are used to the browser back-button, disabling it will in most cases harm the user experience.
Reason for my vote of 4 \n You cold have formatted this in a table like way... SP on one side and triggers on the other, would have made it easier to relate.
Anyway, one should run as far as possible from triggers... :)
True, POSTs don't have cache problems, mostly because they don't use the querystring to pass the parameters.
The "problem" is that I use GET to retrieve data from the database and POST to anything else, following the HTML standards.
I had noticed the cache option on $.ajax but thought of it as somthing I could enable if I ever need it, not as something I had to disable to avoid problems :)
Since I discovered this I disable cache right on the $.ajax global configuration and enable it explicitly on the requests that can make use of it.
Yeah, makes sense since the whole system.web namespace seems to be left out right?
Currently all my apps are web-based so I never had this problem, I'll give it a try when have the time.
Eish... sorry mate, I just updated the link.
The browser freaked out when I was posting the answer and I ended up messing the links.
Next time I recommend you read the specs.
It does handle collections quite well, I'll update my alternate.
Last Updated 1 Jan 1900
All Rights Reserved.