• 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 all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Passwords and Cookies in Servlets - 4b

Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,

I'm getting back into the saddle here after a few months out to pasture and had a couple questions regarding Servlets 4b.
It mentions the method to retrieve values from a Cookie. But, the instructions do not mention what we should do with this value.

Are we supposed to compare the value of the cookie to some expected value? In this case it is a password. But the only way to do that is to store the password as a string when it is entered. I thought it was not a good idea to store passwords in this way.

Am I missing something or did you have something different in mind?
Posts: 23216
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Never store passwords in cookies.

In fact, when you get a little more skill under your belt, you should never store a password ever. But that is another discussion for another day.

What you are going to do is to store something in the cookie that is your own personal proof that you know that you wrote that, not some hacker. For the sake of this assignment, response.addCookie( new Cookie("favorite_cheese", "extra stinky bloo cheese") ); is acceptable. For the real world when the data does not have particularly great value, writing "dfwegx", "94tuw62k" is probably good enough. For higher security, you might work in an obfuscated time/date algorithm with a CRC or rich hash.

Not so fast naughty spawn! I want you to know about
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic