I would like to know how to automatically send an email to confirm their subscription to the users who sign up. Basically, when a user signs up, it adds a line in a SQL database.
Thank you very much, I hope this is clear.
You should do it on your language level.
Related
Fortify lists outputs the following line as vulnerable to attack under the category - Password Management : Hard coded Password. Though I've not hard coded the password. Why is it showing that as a vulnerability, and how do I fix it?
txtPassword.style.visibility = "visible";
Thanks in advance!
I do not have visibility to the internals, but it appears that as part of the 'Structural Analyzer', the Fortify tool searches for text that may indicate that there is a password stored. It cannot tell if there is a password hard coded, but, based on a conversation with an HP Fortify consultant, Fortify leans toward flagging an issue if at all in doubt, allowing the person(s) remediating the audit information to determine if it is a vulnerability or not.
The following text example trigger a line of of code to be flagged my code base.
Password
password
Passwd
passwd
There are a couple of ways to remediate the issue and the correct one for your organization may depend on the work effort:
Mark the flagged issue as 'Not an Issue', indicating that this is a variable/control name and that a password is not hard coded in the code.
Rename the variable/control name to something that would not be flagged - txtPwd may be an option in this case.
I know NOTHING about mysql so please bear with me.
I use something called livesite for my website app and it creates these things called forms when anyone can post on my site. I didn't know about he forms when I setup the site and now I have 75000 spam forms submitted. I still don't know how people (or robots more likely) are doing it, must be a back door somewhere.
Livesite only allows you to delete one form entry at a time which will obviously not work for me.
I know the back end is mysql but my ISP will not help because its not their problem.
Can someone please give me the absolute idiots guide to deleting a bunch of records in mysql. All the records look like this on the livesite management page:
What is the simplest way to make a page accessible by username/password? In school I learned to do this on the server side using sql and java. I'm wondering is there a way to do this only on the client side?
EDIT: lol... based on the responses, I probably should say why I specified client-side. I'm being asked to load an extra page into our company website that is supposed to aid some of our employees. I didn't design this extra page, and I was asked to put this up with a very simple log in. Granted I need to confirm with my superior that a client side login is ENOUGH, I just wanted to know if it could be done IF they decide that it's not all that important. The page itself won't have a link on the site, so unless someone knows it's there or decides to snoop, nobody will even know it's there.
You can save your page into a directory protected by .htaccess file.
That would be server side (you have to upload a .htaccess file into the directory).
But client side? Hmmmm the only thing I imagine is to create a DIV with position: fixed that would be over all your page content.
Ask for a user and a password, then check them using Javascript (this is client side), then you add property "display: none" to the DIV that is containing the login view.
That would hide the login view and show the page that is below it.
This is a HUGE security problem in my opinion. I could easily edit your web with Firebug and add Display: none to the div without entering a password.
However, as the password IS in the Javascript I could look at it anyway just viewing the source code.
The easiest is probably server side apache authentication. Use these two generators for that:
http://www.htaccesstools.com/htaccess-authentication/
http://www.htaccesstools.com/htpasswd-generator/
Just on the client side, using javascript it's never secure enough. But there is way:
if( prompt('Enter password') == 'password' )
{
// we are okay
}
else
{
// password is wrong
}
For more robust example, with username see http://jsfiddle.net/7mZYQ/2/
Well you could try a basic JavaScript dummy with HTML inputs that would somehow offer the slight illusion of password protection. Otherwise, create an HTML form and go with PHP Sessions. These are probably the languages with the most tutorials around so it wouldn't take you that long to pull it off.
You cannot do this securely only on the client side, it would require you to perform authentication of the user inside the browser. This means your whole userbase would have to be loaded in the browser memory in some form, likely in javascript which makes it unsafe.
For a simple authentication mechanism which involves the server to a minimal extent look at Basic Authentication.
No, it cannot be done on the client side. At least not in a secure manner. Client side (password ) validation is very easy to bypass, because clues (such as the password and/or the content you want to show when the correct password is entered) are given to the user.
If you think about what "client-side" means, you'll understand why it wouldn't be possible. On the client side, all information is processed and all data is stored on the client's machine. Thus, in order to check passwords totally on the client side, you'd have to have the entire list of usernames passwords saved to every single computer that your site interacts with.
Keep in mind, also, that anything "client side" is inherently less secure than it would be server-side. So even if you could do this, it'd probably be a bad idea.
Now, that being said, here's how you could do it:
Come up with a password (note that you'll have to use a master password, not individual ones), hash the password, and store the hashed password in a variable, or something. It may sound insecure, but if you're hashing the pw, you could send everyone a personalized email with the password and it wouldn't make it any easier to hack. Hashing is a one-way operation. There is no way to reverse engineer it. Do make sure to make your stored password a constant, though, or someone could just change the value of their hashed password last minute to match your stored one. Give the css rule Display:none; to your data with css so that it hides. Now prompt the user for a password. Then, take that password and run it through the same encryption as you did when you created the password. If that value and the one you stored match, bingo. Just revert your display:none; and you're good to go.
Though I guess that still leaves the problem of somebody just firebugging your display:none away. Guess you'd have to encrypt the data on the page too.
I'm hoping this isn't harder than it seems.
I want to create an HTML form with a few text boxes that will allow people to enter in some data and I want these changes to be saved to the form.
For example, if my html page says:
Name: [ ]
...I want someone to be able to click on the [] and enter their name, etc. and click SAVE
and then have the form say:
Name: "Name of Person"
If someone wants to update that, they can click on the person's name and change it and click SAVE and have the HTML form update itself.
How can I do this? I've looked everywhere and people are talking about HTML5 AND PHP. Is it really that complicated to make a simple page like this?
(In case I wasn't clear in my html I'm using the contenteditable="true" option. How can I save those changes?)
I think your question indicates that you don't already know that web pages (including forms) are "stateless", meaning that they do not "automatically" hold or store anything that you do with them. Sorry to disappoint, but as a beginner you will struggle to find "an easy" solution to this.
That is not to say it can't be done - you no doubt see it everywhere - but your level of knowledge misses the fact that you need to actually program the logic to determine how your form will "appear" to store the information and reproduce it on a later visit.
Here's a (really) brief summary:
When your form is used by your user, a couple of things have already taken place before they get to see the form:
the user has requested the page (typing a URL or clicking a link)
the web server has sent the requested page (that is; your website has sent the form)
The next thing that takes place is that your user enters some data on the form. This data is not stored anywhere - if you refresh the page the data is gone, because steps 1 and 2 happen again.
So to avoid this you can use a number of tools:
Javascript: this operates on the user's computer. You can use it to find out if something has been entred on a form, and store it in, for example, a cookie.
Then you will have to build some logic into your page that says, "if my user refreshes the page or comes back to this site at a later date, then look for the cookie. If it exists, then take it's values and pre-fill the form, before the user gets to see it."
Server Side Script: This logic can be built into your web server (using a server side script like PHP) so it actually runs in step 2.
Alternatively you can build it into a javascript function which fires when the page is actually received by your user. This would be a step 3.
A second alternative combines these two ideas (processing on the user side and processing on the webserver side) called AJAX, which basically means that the "discussion" between your javascript and PHP takes place "on the fly" when the data is entered or changed.
And lastly you might want to consider PHP Sessions to store data, and/or a mySQL database. Recently with the advent of modern browsers you now have the possibility to store the information in a local database available to your user's browser...
In all of these cases you will need to learn how these pieces talk to each other, how you retreive the information, and how you update your stateless and static form.
It isn't has straightforward as you might think...
You don't need HTML5. HTML4 is good enough :)
But you need some server side script that saves the changes (on the server side in e.g. a DB or XML file). To make it a better experience (if multiple users use the form at the same time) I suggest you use AJAX to save the changes and poll the server for updates.
This is not complicated (at least I don't think it is), but it seems to be a generation ahead of what you already know. And it could take quite a long time to get the structure in place before you can do this sort of thing without needing help.
There are some basic questions
Does the information need to stay saved when the user hits reload?
Does the information need to stay saved when the user clears cookies?
If the information can be blanked out next time they come back to your page, then it is simple.
Otherwise, we need a way to keep track of which user sees what information, so the guy in Texas does not see the information the guy in Chinatown typed in. Cookies are a common way to do this. You could save the information to the cookies if there is not too much information.
Otherwise, you need sever-side language. This is usually in PHP, but deciding what language has to do with why you want to learn in the first place? Are you wanting to work for a company later on? Do you have your own website?
Please comment to let me know more what is going on, and what the answers are to the two basic questions, and I will better be able to answer.
Usually, for most cases, there is a login name and password (or OpenID), and if cookies are cleared, the user logs in again, but this requires some work to set up a working login before you re-visit this question of how to store what they type.
We seem to have a lot of clients asking us to change the login screen in this manner:
Display a list of all available users (thumbnail picture + name)
User selects a username from the list
A password prompt appears near the username
User enters password then presses enter
This sounds remarcably similar to the Windows XP login, which is probably where they got the ideea in the first place. There are only about 4 - 5 different users that can login at any given station, so implementing that list on one screen is feasable.
So I was wondering if there are any usability experts with some word on this method of login. As far as I can tell, MS droped this behaviour in Vista/Win7, didn't they?
Providing user names should not be a security issue, think of all the email sites (hotmail, gmail, yahoo) where the email address is the username.
As for usability this is far better then expecting a user to remember their login name especially for user who are infrequent or have a lot of different user accounts.
Please remember to advise users on how to pick a secure password, the weak/moderate/strong as you type color indication while setting the password is a great device for reminding users of the strength of their password.
Windows 7, while not part of a domain, still uses this approach.
While there are few enough users that they can all fit on a screen or a scrollable list this seems like a good idea. As you get more users you may want the option of select from the list or type user name here, style login.
The downside of this approach is that it exposes the list of valid usernames to anyone who can access the login page. And also, as you've hinted at, it isn't very scalable to a large number of users. However if you've got an internal application with only a small number of users then it probably is a usability improvement. Alternatively, you could just implement a "remember me" feature so that a user's name was remembered and they just need to enter a password when they return to the application.
From a security perspective, this sounds like a bad idea. Your username is one of the unique pieces of information that identify you. Granted, with such a small group, most people already know each other's username, but still, I would think at least 2 pieces of personal info (username, password) should be required to login.