Had a hard time developing my site. One of doubting challenge would be SEO. We all know (ok, maybe not really), that a site is friendly to search engines when contents can be "somehow" readable to the search engine crawlers. The site I'm making now is not for a popular brand that people already know. So, every web crawler's effort is appreciated.
If we send the data thru XML, we are sending the raw information using our own format. Google, Yahoo or Bing won't know that a text I've enclosed with some name tags is for, other than it is a readable text, something that can be matched with related informations.
So, the present that XML data to a human user, we have to transform it HTML that the browsers can understand, using XSLT. During testing, I have noticed that the browser caches few files, which made me conclude that, it really does save bandwidth problems for high-traffic sites.
Added up with HTML5 (which gives me some real pain in the neck, thanks to stubborn as ever, IE), it is possible to make cool web UIs. I already up'ed the site, and will see in weeks how the contents result in major search engine results.
Using MVP Pattern + XSLT
I just finished developing my web framework in MVP and now, it is time to do work on the client side. XSLT made the missing piece I want for my website complete. Using this, data will be presented in pure XML, which means datas on the website can be easily re-used on different platforms, and even javascript too, which is nice.
This doesn't limit my site to just have a passive view. I can still have all those input fields and accept all those user input datas, yet my site will be in XML form, web crawlers can easily see my site, no unnecessary SEO paranoia things, hehe.
All this facts leaves me to one last task, mapping each request in IIS to make those URLs pretty to search engines.
UPDATE:
I tried some dynamic XSLT approach, Chrome is OK, IE is OK (even 6.0), but FF (3.5 and 4.0)gives an error... I think I need to make a good re-write rule to trick FF that the xsl file referenced is a static one.
This doesn't limit my site to just have a passive view. I can still have all those input fields and accept all those user input datas, yet my site will be in XML form, web crawlers can easily see my site, no unnecessary SEO paranoia things, hehe.
All this facts leaves me to one last task, mapping each request in IIS to make those URLs pretty to search engines.
UPDATE:
I tried some dynamic XSLT approach, Chrome is OK, IE is OK (even 6.0), but FF (3.5 and 4.0)gives an error... I think I need to make a good re-write rule to trick FF that the xsl file referenced is a static one.
Top 10 Web Application Security Risks
What makes Web Application different from Windows apps or other client apps is that it is accessible remotely and all users can access the same application anywhere. This also eliminates the need to have all users install software upgrades, the developer can update the version on the server. However, web applications are prone to security issues like
1: Injection
- Can be done by simply adding input to invalidate SQL query and add their own potentially dangerous query.
- Can be prevented by filtering the user inputs and have the methods accept specific types of data (parameter based query commands).
2: Cross-Site Scripting (XSS)
- Same with injection. If the inputs available to user are filtered,
3: Broken Authentication and Session Management
4: Insecure Direct Object References
5: Cross-Site Request Forgery (CSRF)
6: Security Misconfiguration
- configs
7: Insecure Cryptographic Storage
8: Failure to Restrict URL Access
- disable directory browsing
9: Insufficient Transport Layer Protection
- SSL
10: Unvalidated Redirects and Forwards
Source: OWASP (http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project)
1: Injection
- Can be done by simply adding input to invalidate SQL query and add their own potentially dangerous query.
- Can be prevented by filtering the user inputs and have the methods accept specific types of data (parameter based query commands).
2: Cross-Site Scripting (XSS)
- Same with injection. If the inputs available to user are filtered,
3: Broken Authentication and Session Management
4: Insecure Direct Object References
5: Cross-Site Request Forgery (CSRF)
6: Security Misconfiguration
- configs
7: Insecure Cryptographic Storage
8: Failure to Restrict URL Access
- disable directory browsing
9: Insufficient Transport Layer Protection
- SSL
10: Unvalidated Redirects and Forwards
Source: OWASP (http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project)
Subscribe to:
Posts (Atom)
