Jump to content
Larry Ullman's Book Forums

bnorcom

Members
  • Content Count

    49
  • Joined

  • Last visited

Community Reputation

0 Neutral

About bnorcom

  • Rank
    Member
  1. Created a contact form based on all the forms instruction you've provided. On page 650 you talk about setting SMTP. My web host had a setting of "localhost" and "port 25" so there was an error. They opened a ticket so they could put the proper mail server address in their php.ini (I wonder why it wasn't set properly in the first place). You talk about restarting the server after making the setting change. It seems that a client/user couldn't fix php.ini himself anyway, and a host doesn't reboot his server just any old time he wants to make a change. But apparently the program based upon your example would have worked if the setting was correct. Is there anything else I have to make sure is set properly with the web host before I continue?
  2. Just used a cookie and it worked the first time. Used "header" to redirect which raises one question. In your examples you use the absolute path. You'd think if the destination was in the same directory that you could just address that page instead all the way from the root. Discovered from reading In your book about sessions that the browser itself handles the back and forth transferring of the cookie. I suppose there's a lot to learn about all the things browsers do. A subtle question in my earlier request had to do with getElementById and jQuery. I was wondering if PHP existed mostly in its own world and would interact with JavaScript and JQuery just like HTML, or maybe it had certain relationships built in developmentwise.
  3. Thanks for the answers. Since I've never used cookies I just have the idea of the word in my mind that it's just simple for misc things. In Asp.Net I used sessions and the cache which seem more solid. So when I saw an author using Header I thought he was going to a more secure level by having more control by passing the data that way even though I was thinking it still wasn`t very secure. So I'll start studying sessions to go for more security. I'll keep in mind that cookies aren't just floating around if you can find them.
  4. One question leads to another. Script 12:1 posts to itself with <form action='login.php'>. Then if successful there is setcookie('user_id', $userid). But a cookie is on the client, so when redirected to loggedin.php (script 12:4) there is "if(!isset($_COOKIE['user_id]))" which means the client has passed the cookie to the php server for the test. I read somewhere that the user id value can be passed in a querystring with "header('Location: whereto.php?user_id' .$userid);" Then a cookie is unnecessary because of "$user_id=$_REQUEST['user_id]" Cookies probably aren't that secure, but I suppose parameters being passed aren't either. That is why you say on page 404 "for most web apps use sessions."
  5. I tested according to the book's example and it worked the first time. I thought there might be duplicate emails so it made sense to search for both email and password at the same time. It occurred to me that PASSWORD_DEFAULT would use different salt codes each time and I'm happy to find out my logic is working. What's helped me with validation is jquery.validate.min.js and jquery.validate.password.js so thought I'd pass it on. But I must say the bootstrap-navbar css you use would take some study to fully understand it. Do large groups of people use all of that as if it's an industry standard? Also your other book with sticky forms uses the syntax <input name='eaddr' type='email' id='eaddr' value='<?php print $eaddr; ?>'> However I encountered in another book <a href='<?php echo $email; ?>> etc. Are the commands echo and print exactly synonymous so is it just a matter of programmers' preference? Here they save directly in the value property via the php script. But in JavaScript you'd use getElementById, or with jQuery via Ajax responding to an event, you could use $('#eaddr').val(obj.eaddr). However you can't "call" an event so php's echo/print becomes more powerful than it's nomenclature connotes. Also I read about Immediately Invoked Function Expressions. But since php has server-side interpreter scripting it seems that an IIFE would be unnecessary.
  6. OOPS. There's a typo in the above sql stmt of an extra $pwd= that shouldn't be there.
  7. Chapter 13's login_functions.inc.php uses: $q = "SELECT user_id, first_name FROM users WHERE email = '$e'"; if(password_verify($p,$row['pass'])) I coded something different which should be the same: $eaddr = filter_input(INPUT_POST, 'eaddr', FILTER_SANITIZE_EMAIL); $pwdkey = filter_input(INPUT_POST, 'pwdkey', FILTER_SANITIZE_STRING); $pwd = password_hash($pwdkey, PASSWORD_DEFAULT); $sql = "SELECT user FROM student WHERE eaddr='" . $eaddr. "' AND pwdkey='" .$pwd='" .$pwd. "'"; if($result = mysqli_query($dbc,$sql)) I have to test it more ,but since the query didn't return any rows, it makes me think that a hashed form input being compared to a 256 byte hashed data field in the database is too much to ask. Perhaps your approach is less intensive and/or easier.
  8. In the beginning it seemed to me that PHP was creatively free-form. In Applesoft Basic they progressed to top-down design and ASP.Net has serverside processing and ViewState. In a PHP book I read an author saying "a script that submits to itself means . . . you're not going to get a true MVC pattern. You might need to simply accept that PHP is often going to cause you to sacrifice really clean MVC at the altar of getting things done." I guess that means that a PHP shop doesn't necessarily have an industry standard as long as it works.
  9. Password.php (script 9.7) is a standalone page because its FORM posts back to itself. It has an organized framework starting with testing for POST and then validating the input. If error free it tries to find a match using the email and password fields. Then if so, action is taken. If not, then matching and/or system errors are printed as well as validation errors. But it is not an included page. However, it could be streamlined using login_functions_inc.php. Check_login handles input validation, matching and error reporting. Therefore why not just make calls to those functions from the main page to simplify the look of the code? Next, login_page.inc.php (script 12:1) proceeds to modularize. The comment says "it creates the entire login page." But it doesn't even post to itself and you'd think at least validation would be done in the same place where the form exists. It gets posted to login.php which takes control (but wouldn't have been called to start it off) and then includes login_page. The comment says it "processes the login form submission." Check_login lumps together validation, matching, and returning almost looking like password.php which hopefully was meant to be streamlined. I can't see what is meant to be an improvement since the modularization seems to have just gotten more complicated. So I can only conclude that in a big company it is necessary to create substantially-sized modules so everyone can piece them together as needed in a "black box" scenario.
  10. It's funny I thought maybe the first name was questionable. I was learning the password stuff first and wasn't thinking cookies/sessions. Then I saw that the name was stored in the cookie. There sure are a lot of modules going from the first password page and then to the login page using the functions and on to logged-in etc. Of course, at the end of the book there's the AJAX approach. I guess the larger the business the more compartmentalized it all is where each module is used by everyone in their own way. It's mind-boggling to try to figure out which approach to use depending on whatever the situation. It must be like learning a language where you can't really speak intelligently until you know all the basics and are fluent.
  11. Since this is an open thread and you answer quickly I'll put an errata question here. On page 456 of chapter 13 statement 55 gets the user_id and first_name. Then in statement 65 it refers to $row['pass']. But in order to verify, it would have had to select the stored password which wasn't selected, so I was wondering if the first name selected should have been the password. The entry of the password text by the user apparently is VERIFIED by PHP comparing it to the hashed password which is in memory having gotten it from the SELECT. I'm studying to use it now, and it could be "over my head" so I'm not seeing the big picture. But they say "there's no such thing as a stupid question."
  12. Thanks for the help. I thought when you uploaded files to directories at your web host and executed programs there, the paths were synonymous so there was nothing to worry about. For example, when I developed some stuff with ASP.net I always had to be concerned with closing connections because there is the error of "maxed out the number of open connections." Apparently PHP closes them when to program finishes so there isn't the same concern. I was curious so I reviewed Script 9.2 on page 271. Line 14 says "... OR die('Could not connect etc'). I wasn't using the "OR" but was using "if(mysqli_connect_error() {(echo "No connection because etc). Then after the include I continued with "else {" and then code from my program. Your mysqli_connect.php doesn't have a ?> close. Could my maybe having closing with ?> short-circuited processing so the program never continued? Or could the "die" v. "connect_error" language have complicated things too much? That's why my brain is still fuzzy about includes everywhere.
  13. With Windows I've always treated "root" as the top level with main pages so when I use "/" at the start of the path it creates an absolute starting place which is the root. I've always assumed that a Web host isn't going to let you up any higher than your domain's root location. In beginning textbooks PHP always seemed to call their pages "scripts." So I put, for example, connection pages in the scripts folder which is accessed by /scripts/connect.php. But includes also have PHP extensions, so they could be considered scripts too, however their purpose may have a more important "include" role. I resorted to putting the connection variables in a place in the scripts folder, and the actual connection code remains in the main page. Even if it's in the directory structure, you can't run that page and see the parameter data because it looks like it can't be viewed that way. I don't know what difficulties were involved doing it the first way, but this second way works, and even looks more straightforward.
  14. RE: includes. Your example puts the database parameters and connection in a separate file and requires it. I put that file in a scripts folder at my Web host and the main page is at the top which is where I get into using "/" or "../". But in tests it produces a #500 server error at the host. I contacted them to see if they have PHP errors activated and they do. I've tried all kinds of path combinations for the include to no avail. Then when I replace the include with the hard code the database access works and there is no server error. At first I used DEFINES like you use in your example and then wondered whether that is only class oriented and works only at certain locations in a program. So I switched back to the way I coded everything at first and it worked fine. There are some particulars using includes for certain things that I must be unaware of and don't understand. Unless I can figure out the mystery I'll have to work on it later when I have time, but at least I know what will work.
  15. I'm starting to program the login process and have a few relevant questions. The first is why do the forums require a username whereas the book uses an email address instead? I thought emails were more common these days. The second deals with the purpose of includes. For reuse it makes sense for maintenance, but I've found if one little part is different, then a separate include is necessary. Includes are nice to simplify the main part, but if they then complicate things by their isolation they make it harder to test and find errors. The last question is about specifying a path with ../ or not. Keeping track of where the program is at to know whether to go to a subfolder or up to the parent is tricky. I thought that a slash at the start of a path always meant starting at the root. But I'm wondering if PHP itself has rules of its own or do all host's operating systems use an industry standard?
×
×
  • Create New...