Monthly Chronicler Password Protect Tutorial
When you have sensitive data involving personal information and monetary matters you ideally need to …
- involve SSL (ie. https: type URLs) … and as far as passwords are concerned …
- it is best to hash your passwords rather than encrypt them
… but just bear in mind there is a fair bit to that latter idea. Today, we are going to offer users a way to shield prying eyes from seeing their “diary” entries with our “Monthly Chronicler” web application, but we will not be hashing passwords to achieve this. Please do not think that none of the concepts below will not affect your security of data here …
- somebody clearing the web browser cache … though the affect of this is that your data is wiped rather than found out
- somebody examining the HTTP Cookies separately to find your data … there is mild encryption, but as you will read on the “net”, encryption is not enough for true password protection, database usage with password hashing is much better
… nevertheless, for the most part, what we do today extending the functionalities introduced with yesterday’s Monthly Chronicler Primer Tutorial serve a purpose for the vast majority of users on the net, that being if you indicate that you want some data not to be shared, then the user, as a reasonable person, will oblige, and not go snooping.
Our simple approach today is that with either or both …
- personal details … and/or …
- any date clicked/touched to chronicle something
… now has functionality available to the user (by appending ?password=[theirPassword] to their displayed data) to password protect the current web browser and https://www.rjmprogramming.com.au/HTMLCSS/monthly_chronicler.html usage pairing. Others not knowing this password (and personal details pairing) can still use the web application, but any HTTP Cookie stored information “does not stick” for them.
Feel free to rejoin us, trying it out at (the changed) monthly_chronicler.html‘s live run link.
Previous relevant Monthly Chronicler Primer Tutorial is shown below.
Monthly Chronicler Primer Tutorial
We’ve got a new web application for you today. We’re calling it a “Monthly Chronicler”, which is a web application like a “Calendar” or “Planner” or “Diary”, where the user can personalize the entries according to a date, with whatever information they want.
This idea is of limited applicability unless it is a bit accountable, and at this first draft, the accountability comes in the form of saving a user’s personalized data into HTTP Cookie data form. As you might know from online shopping experience that you have, the use of HTTP Cookies can mean a web application can resume another call of the web application and load in your previous data, ideal for a “Monthly Chronicler”.Other features are …
- use of HTML details/summary element pairing (to allow for display. or not, of previously entered data) … nesting …
- use of HTML div contenteditable=”true” (for ease of user editing purposes)
Join us trying it out at monthly_chronicler.html‘s live run link. With such a web application it can suit being a web browser’s home page to …
- just show you your calendar of entries for the current year ( https://www.rjmprogramming.com.au/HTMLCSS/monthly_chronicler.html )
- highlight today’s date on the “monthly chronicler” ( https://www.rjmprogramming.com.au/HTMLCSS/monthly_chronicler.html?today=y )
- click today’s date ready for you to “diarise” ( https://www.rjmprogramming.com.au/HTMLCSS/monthly_chronicler.html?clicktoday=y )
- show a previous year’s activities ( https://www.rjmprogramming.com.au/HTMLCSS/monthly_chronicler.html?year=2017 )
If this was interesting you may be interested in this too.
If this was interesting you may be interested in this too.
