Comments by AlexCode - CodeProject

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.

Comments by AlexCode (Top 10 by date)