• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How to check in java class if Javascript is disabled

 
Ranch Hand
Posts: 367
Eclipse IDE Opera Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I need to check in my java class the status of the javascript (whether it's enabled or disabled) and based on that few validations will be performed at server side.
If your suggestion is to use noscript, could you please provide a small example for xhtml.
My project works on Spring web flow.

Please advise.
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Your class should not care whether JavaScript is enabled or not. It should always perform all validation checks regardless of whether you think these checks have already been made at the client or not. Anything short of that is irresponsible security.
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
+1 to what Bear said.

To take that even further, your application should not even assume the data is coming in from an HTTP request. Not only is relegating security checks to the client alone poor security practice but it can also lead to other kinds of problems. If you couple your validation logic with the fact that most incoming data will be from HTTP requests today, this will likely put you in a bind when you have to accommodate different sources of data such as a file or a message queue later on. When that time comes, most developers will likely just go ahead and duplicate the validation code rather than spend time refactoring to move the validation logic to a layer that is more easily accessible to different data intake methods. This will lead to more problems and the negative effects will snowball.

So, make the effort to do the right thing and move the validation logic away from any single point of entry into your application. Don't assume that incoming data is always going to be from an HTTP request and don't trust any incoming data, even if you think or even know for sure that the client already performed validations. Mark Twain wrote, "It ain't what we don't know that gets us in trouble, it's what we know for sure that ain't so."

A book that was recently promoted in the Security forum, Iron Clad Java, is a great source of information for better secure coding practices, including validating incoming data.
 
pramod talekar
Ranch Hand
Posts: 367
Eclipse IDE Opera Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks a lot Bear and Junilu. I have solved it.
 
It is no measure of health to be well adjusted to a profoundly sick society. -Krishnamurti Tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic