• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 292
  • Last Modified:

When is HTML encoding necessary?

I created a home grown Single Sign-On and have it working where one site has a button which opens up the second website. I create a link with username and a time stamp and read the "un" and "ts" variables in the Global.asax.cs Session_Start() succesfully.

http://localhost:3291/?un=username&ts=353666232

It's working fine, but it's not yet endoded. I am testing it internally, and never expect to release it over the web. It's an internal website for internal use.

I do plan to encrypt the username and timestamp later. For now, please explain if I need to add HTML encoding, and why I need it.

Thanks,
newbieweb
0
newbieweb
Asked:
newbieweb
3 Solutions
 
Paul MacDonaldDirector, Information SystemsCommented:
It wouldn't appear you need to do any encoding.  If you were going to pass parameters that included special characters (quotes, ampersands, etc) that mgiht otherwise be interpreted by the browser, you might want to encode those values.  Since it seems you're only passing numbers, there shouldn't be any problems.
0
 
wdosanjosCommented:
I agree with paulmacd, no encoding should be necessary.

You should consider though not passing the username as a parameter due to the security risks (an ill intended user can potentially "pretended" to be another).  I recommend that after authentication you generate some type of encrypted token that only your code can decrypt to extract the user info. And you pass that token along.

 
0
 
John ClaesSenior .Net Consultant & Technical AnalistCommented:
The Encoding is only done to ensure that your browser sends it as a Parameter and is not looking at it.

Example :
You want to send a string as parameter to your page : something like
"this is a text with some chars like & in it"
Now you know that Url's split parameters using the & sign, so if you send it like it is the browser will split your string into 1 recognized string "this is a text with some chars like" and the rest will be excluded from the string.

Therefor we use UrlEncoding:  this will change our example string into
"this+is+a+text+with+some+chars+like+%26+in+it"

As you can see spaces are changed into + and our & is changed into %26
Now our browser will send the string directly and will not look at it.

When using encryption and special chars you always should do it.

A best practice that I personly enforce in my projectGroup is that every parameter set in the Url or is send is always encoded. Just to ensure that special signs are permitted (even when they're out of scope at the moment)


regards
poor beggar
0
 
newbiewebSr. Software EngineerAuthor Commented:
Thanks!
0

Featured Post

[Webinar On Demand] Database Backup and Recovery

Does your company store data on premises, off site, in the cloud, or a combination of these? If you answered “yes”, you need a data backup recovery plan that fits each and every platform. Watch now as as Percona teaches us how to build agile data backup recovery plan.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now