15,890,438 members
Sign in
Sign in
Email
Password
Forgot your password?
Sign in with
home
articles
Browse Topics
>
Latest Articles
Top Articles
Posting/Update Guidelines
Article Help Forum
Submit an article or tip
Import GitHub Project
Import your Blog
quick answers
Q&A
Ask a Question
View Unanswered Questions
View All Questions
View C# questions
View C++ questions
View Javascript questions
View Visual Basic questions
View Python questions
discussions
forums
CodeProject.AI Server
All Message Boards...
Application Lifecycle
>
Running a Business
Sales / Marketing
Collaboration / Beta Testing
Work Issues
Design and Architecture
Artificial Intelligence
ASP.NET
JavaScript
Internet of Things
C / C++ / MFC
>
ATL / WTL / STL
Managed C++/CLI
C#
Free Tools
Objective-C and Swift
Database
Hardware & Devices
>
System Admin
Hosting and Servers
Java
Linux Programming
Python
.NET (Core and Framework)
Android
iOS
Mobile
WPF
Visual Basic
Web Development
Site Bugs / Suggestions
Spam and Abuse Watch
features
features
Competitions
News
The Insider Newsletter
The Daily Build Newsletter
Newsletter archive
Surveys
CodeProject Stuff
community
lounge
Who's Who
Most Valuable Professionals
The Lounge
The CodeProject Blog
Where I Am: Member Photos
The Insider News
The Weird & The Wonderful
help
?
What is 'CodeProject'?
General FAQ
Ask a Question
Bugs and Suggestions
Article Help Forum
About Us
Search within:
Articles
Quick Answers
Messages
Comments by AlexCode (Top 10 by date)
AlexCode
8-Aug-14 4:33am
View
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.
AlexCode
5-Aug-14 5:20am
View
But how did he get the valid Admin session token?
Either he:
- 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.
AlexCode
8-Aug-13 5:19am
View
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
http://json.codeplex.com/
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.
Cheers!
AlexCode
7-Aug-13 2:56am
View
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?
AlexCode
7-Aug-13 2:38am
View
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.
AlexCode
24-Jul-13 4:03am
View
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... :)
AlexCode
15-Aug-11 14:28pm
View
Deleted
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.
AlexCode
21-Jun-11 3:01am
View
Deleted
Yeah, makes sense since the whole system.web namespace seems to be left out right?
Edit:
Just went to see the Client Profile definitions and although I haven't tested it, the JavaScriptSerializer should work, at least I don't see its namespace as excluded.
Currently all my apps are web-based so I never had this problem, I'll give it a try when have the time.
Thanks!
AlexCode
17-Jun-11 17:58pm
View
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.
Cheers!
Alex
AlexCode
14-Jun-11 10:39am
View
Deleted
Next time I recommend you read the specs.
It does handle collections quite well, I'll update my alternate.
Show More