Stefany93

Oh, too bad. I hope more people express interest in the future. Writing tutorials help both and writer and the reader improve, so I think it is nice.

I plea the leaders of this forum to put a "Tutorials" section where users can post programming related tutorials with the purpose of educating their colleagues.

Yup, the (*) operator is messing up your results, like the colleague above said. Never use the * to fetch everything from the DB because it makes it run way slower and if you add more columns you would need for special occasions only, and you fetch 'em all at every query, that will slow down your application greatly.

Glad I could help. Usually, I will avoid nesting functions like hell because a) it makes the program run slower, kills readability and some functions work while nested within another and some don't which can drive ya crazy. Better approach will be: if(isset($_POST['field_name']) and !empty($_POST['field_name'])){ $field_name = trim($_POST['field_name']); } Now, in the past, when I was green, I would use $_POST['file_name']; without assigning it to a variable like $field_name which proved to be stupid because if at any time you want to change the name if of the input field you are fetching the information, then you'd have to change tens of $_POSTs in your code. The same in JavaScript. If you have like <h1 id="main_header"></h1> and you want to fetch it with document.getElementById('main_header'); it is better to put in a variable like this var main_header = 'main_header'; and you wouldn't have to worry about the ID being changed. You could just then change a single variable.

Using var in front of JS variables ensures: 1. That you are following a good programming practice; 2. The creation of a scope of the variable (As Josh above pointed out); 3. Better readability, since seeing var in front of a variable automatically means that this is the first instance of this variable and you are not over-writing another one; 4. That you are a good programmer; Kind of like my in Perl, although not that strict in relation to the scope. I wish they had made var mandatory in JS just like my had become in Perl 5.12 + Do something, Mr Eich!

Good approach, but what I usually do when I write a validation script is that I declare a new array like this $errors = array(); and I append the array with any errors that arise and before doing what you wanted to do with the DB (Insert, Select, Update, whatever) I check whether the $errors array is empty, i.e. whether the validation script gave any errors. If it is empty, execute the query, if not, display the $errors array with a foreach loop to let the user know where he went wrong. And instead of $_POST['field_name'] == null, you can also use the negated empty() function like this !empty($_POST['field_name']) And of course, make sure you escape all use input. Vital rule in programming - all user input is considered malicious unless proven otherwise.

Yeah man, you need to populate your table in order to fetch the data needed for the array. And undefined offset almost always means that you are trying to access an un-existing element of an array. Like an accessing $array[3] while $array having only 2 elements will generate the same error.

If the OP wants to learn how to do it, using a premade script will be a mistake. Even if he wants just to use something ready, it will be a mistake again. Pay a programmer $30 to make a reg script for you, those "premade scripts" are ancient and full with security holes. And if your website is not very big, I'd suggest using SQLite over MySQL.

Howdy folks, After diving into Perl, I managed to write my first "program" or script rather. Basically what I wanted to do was to create an equivalent of the PHP function print_r() for displaying arrays' keys and values and thus helping for an easier debugging. Here is the script: #!/usr/bin/perl # We are telling Perl that # we shall be working in a web # browser and therefore sending # the proper HTTP headers. print "content-type: text/html \n\n"; # Perl version. use v5.16.3; # This subroutine will display # the keys and the elements # of the array # given as a subroutine parameter. sub print_r(){ # $x will iterate through the # @keys array. my $x = 0; # We collect the keys of # the given array in the # @keys array. my @keys = keys(@_); # Display 'Array' before the loop. print 'Array ( <br />'; # Iterate through the array. foreach my $value (@_){ # Print the key of the current value # using $x as an index starting at 0 # and then print the value. print ' ' . $keys[$x] . ' => ' . $value . ' <br />'; # Increment our index variable so that # the next element of the array is selected # in the next iteration. $x++; } # End of the loop. Dislaying the closing the array. print ' )'; } __END__ I have a couple of questions if you guys can help me please! 1. Shall I leave the comments as they were within the subroutine or put them above it? 2. I tried to check whether the parameter is an array with the ref() function, but the problem is that Perl subroutine parameters treats everything as an array, even empty string or a scalar variable as long as it is put as a parameter in the sub call. So I can't really think of a proper check that checks whether for example &print_r(@array) is an array. If any of you can think of tips to give me for Perl, I will be very grateful. I think Perl is an awesome language.

SHA512 is the best hashing function so far in my opinion. Just remember to always salt your passwords before storing them, even after hashing them. No matter what they tell you, without salting your hashed passwords are just a little more secure than plain text.

I am sorry, but just because you use these frameworks doesn't mean that everyone who do not use them are stupid like you are trying to imply. You are just another soldier in the "we use frameworks" army. I am a soldier in the "we do not use frameoworks " army Let's keep it civil...

Well it is too late to move it now by myself.

Sorry, I was searching for the correct category and couldn't find one If a moderator is so kind as to move the topic that will be great. Thanks for the update.

Note: This article assumes you have a basic understanding as to what .htaccess files are, how they work and how to create one. And that you know how to use regular expressions. When we were green programmers, we would create a website with these files: index.php about.php contact.php And when our visitors wanted to access a certain web page within our website, we would provide them with links to these documents directly like this: www.example.com/about.php However, all this above turned out to be the wrong way for many reasons. First of all, referencing web pages with their full name is not very secure because an evil user would know (a where "about.php" is located, b) that it is a PHP file and that will facilitate his work to ruin our website. The correct way to fix this is with a .htaccess file placed within out root directory where our website resides. Before you use your .htaccess file to re-write an URL, make sure your server a) supports .htaccess files because some bosses of hostings forbid them for God knows what reasons and b) that even if the hosting allows .htaccess files, you might need to contact the hosting people to ask them to configure their server to accept URL re-write on a per directory basis. Now we would want to turn this URL http://www.example.com/about.php into http://www.example.com/about Our very first directive must be: RewriteEngine On # We are turning on the rewrite engine on our server Some hostings require you to specify as to from where the re-writing shall begin. Let's say you store all of your website files and folders in your root directory. Then your second directive will be: RewriteBase / # We shall be re-writing files in our root directory. When testing on localhost using the "RewriteBase" directive will give a server error. Our third directive: RewriteRule about about.php Now, golden rule - when re-writing a URL, you must first specify the RewriteRule directive and then the word right after that is the word that rewrites the name of the file whose name you want to re-write. So RewriteRule about means that the word that will come after "about" is the one that will henceforth be known as "about" in this case about.php So: RewriteRule about about.php # Re-write the file name about.php to about So when we write in the URL http://www.example.com/about the server will actually be pulling the information from about.php but the user will never know! That will be our little secret! Now the problem with the above approach is that the re-writed name is not spesific. Meanning that "about" will match any URL that has the word "about" in, for example: http://www.example.com/aboutmyawesomepizza The above will be matched. We do not want that. We can solve this problem with regular expressions: RewriteRule ^about/?$ about.php Super! Now our URL will only match http://www.example.com/about with or without trailing slash, does not matter. One last thing - we want about URL to be case-insensitive so that http://www.example.com/about and http://www.example.com/AboUt will both match the about.php file. We do that by putting the [NC] flag at the end of the directive like so: RewriteRule ^about/?$ about.php [NC] "NC" meanning "no case". I also thought it meant "North Carolina" but sadly it did not. All directives put together: RewriteEngine On RewriteBase / RewriteRule ^about/?$ about.php [NC] More reading: What are .htaccess files? - http://httpd.apache.org/docs/2.2/howto/htaccess.html RewriteRule directive - http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewriterule

// referencing the text box var text_box = document.getElementById('text_box'); // getting the value. We use the annoying alert window method for testing purposes. alert(text_box.value); If that is what you are looking for...

I respectfully disagree - it doesn't matter what method you choose of accepting user input, as long as the input is properly validated/sanitized, then there is no problem. One should not avoid using query string only because they are easily manipulated for evil. You know HTTP headers can also be tweaked for evil purposes, does that mean we should stop using HTTP?

Welcome

These "URL extensions" as you call them are named "query strings" and they are used to pass information whether it be to another file or directly to your CGI program of choice. They are very often used in web programming. To get the value of them, you use the $_GET super global array. For example, if you have a URL www.example.com/blog.php?general=lee and you want to display the value of "general" you do this echo $_GET['general']; However, this approach will throw you a "Notice: Undefined index" when you first load the page before the query string has been appended, so it is better to first check whether value of "general" has been set with the isset() function like this: if(isset($_GET['general'])){ echo $_GET['general']; } And this is not entirely correct either because the golden rule says you can never trust user input so you must always validate the value of the query string with the numerous functions for that, depending on what you need it for. Like if you are going to display that value, you'd need to escape it with htmlentities() or if you are going to compare it in a DB you need to make sure it does not contain malicious code for SQL injection and so on. When you have like two values in the query string like this: www.example.com/blog.php?general=lee&years=53 You just ignore the "&" and get the values by accessing their names like the previous example: echo $_GET['general'], ' ' , $_GET['years']; Query strings are awesome, use them!

Hey fellows! Thank you very much for the advice everyone, but I have decided to trash the whole website and make a new one anew, with my crappy design skills, because I believe that even tho I am world's worst designer, it will look way better than it does now at least. Besides, this website wasn't created by me and that buggs of me off. I told the designer who made it just to send me the PSD files and I would have coded it, but no, he just send me the ready HTML and CSS files... Anyways, thank you again!

Thank you very much for the nice words! You and @requinix are absolutely correct that I should include a description about salting as well, otherwise that makes this manual pretty much useless. I will do that in the coming days, thank you! And WOW, I didn't know that nowadays some guides still recommend MD5(). That's suicide, to say the least!

If we want to create a login system for our website, we must absolutely store two types of data - a username and a password. We store them in the database of our choice (be it MySQL, SQLite, MariaBD, whatever really), and when the user wants to log in, they input their username and password and a script we had written earlier takes care of comparing whether the username password that our user has just entered matches those in the database. If they do, we start a session, and we usually assign it the value of the user's ID. And the user is now logged in. Sounds easy, eh? Our first problem comes with our database design. Let's say we are using MySQL and we want to store the user's username and password. We first create a table in our database and we name it users The absolute minimum of fields required are 3. The user's unique ID, username and password. So now our table looks like this*: users_id users_username users_password Now, let's imagine that we have a user with the username robert with a password marble users_id users_username users_password 1 robert marble Now, the trickery comes here. We store the users' ID with the INT database type, and we store the users' username with the VARCHAR datatype. However, we all know that we can't store the users' password in a plain text because that will just be plain stupid. We need to hash it in some way. Now, when we were young and green, we used the MD5() hash function. That function transforms a given text into a 32 characters string of random numbers and letters. For example, let's hash the password marble with the MD5() hash function echo md5('marble'); // Result: 550a6aee24871befa055ffd52f92eba9 As you see, the string is converted into a hash value that is not possible to convert back to its original string. However, as of 2009, this MD5 has been officially deprecated, and it is not reasonable to use it for storing passwords inside databases at least. So MD5() is out of the game, what does that leave us? Our next option is SHA1() SHA1() does the exact same thing as MD5(), but it converts the string into a 40 characters hash value like so: echo sha1('marble'); // Result: 334851b6547be0d129bf69f984668cfbd70d4da2 As of 2011, security vulnerabilities have been found for SHA1(), so using that hash function is not a good idea either. That leave us with SHA512, the most secure hashing function so far. It's doesn't have its own pre - build method in PHP, but it can be used that way: echo hash('sha512', 'marble'); // Result: 2a7d68bd5ef34809c455209a531318c09c50d92776913b042b384604673e1708620732cdbbea193304130e96102666635c05cb18e03ce6e936bd2ff4c9566a36 Yup, the hash value is that long! 128 characters, no kidding! So far, SHA512 is the most preferred way to use when storing passwords in the DB**. So if we go back to our users table, we shall make some adjustments. We shall give the users_username field unique index, and we shall set the data type of our users_password field to CHAR, since we shall always be storing 128 characters strings, we could use the extra speed CHAR provide us, if we always use the exact number of characters, as declared. Here is how out users table looks like now: users_id users_username users_password 1 robert 2a7d68bd5ef34809c455209a531318c09c50d92776913b042b384604673e1708620732cdbbea193304130e96102666635c05cb18e03ce6e936bd2ff4c9566a36 Notice how we are not storing the user's password in a plain text, but in a hashed value. That way, if, God forbid, an evil user enters our DB, they could only see the hash value, but they would never know the real password, since it is impossible to reverse the hash back to its original text. Here is how we write a script that compares the user's inputted data with the one in the DB. Please don't use this code for production, since it is a security risk, because I haven't validated or sanitized any of the user's input, I am just using this code as an example. if(isset($_POST['username'], $_POST['password']) and !empty($_POST['username']) and !empty($_POST['password'])){ $username = trim($_POST['username']); $password = trim($_POST['password']); $password_hash = hash('sha512', $password); $query = $db->prepare("SELECT users_id, users_username, users_password FROM users WHERE users_username = :username AND users_password = :password"); $query->bindParam(':username', $username, PDO::PARAM_STR); $query->bindParam(':password', $password_hash, PDO::PARAM_STR); $query->execute(); $results = $query->fetch(PDO::FETCH_ASSOC); if(!empty($results)){ $_SESSION['user_id'] = $results['users_id']; echo 'Logged in!'; }else{ echo 'Wrong username/password!'; } } * I like to prefix the field names with the name of my table, but you are free to name your table fields anything you like, really. ** Please note that I am only talking about hashing, it is advisable to use salt to better secure your passwords when comparing them.

Thank you soo much! So I will change font - family of the logo and I will make it without shadows. I am sorry, but when I click on the forum button, it works. I have no idea why it didn't work for you tho...

^^ Thank you for the replies everyone, but I don't want to buy a theme because they are made for people with no idea about programming and websites, while I know how to create website, it is just that the design part is running away from me...

Hello fellows, I have been receiving a lot of hate mail recently that the design of my portfolio website is pretty much lame. Please note that I hired a designer to make the design of my website, basically, because I am a very crappy designer myself, I am only concentrated back - end. But still, having a totally ugly website is still not a good idea, so please folks, tell me kindly what I can do to make it look prettier because I have absolutely no idea! Here it is: http://dyulgerova.info Thank you so much! EDIT: Sorry guys, I messed up the title...