Jump to content

Psycho

Moderators
  • Posts

    12,145
  • Joined

  • Last visited

  • Days Won

    127

Everything posted by Psycho

  1. One thing I will point out in QuickOldCar's code that may not be obvious. You will notice that the file doesn't start with "<HTML>". It instead starts with the PHP processing logic. Then, after all the processing is done, he builds the page. There are many reasons why this format should be followed and his implementation includes one such example. After all the processing logic is done there is a condition to test whether registration passed or if there was a failure. If registration failed the logic will continue to the output of the form (as well as the error message). however, if registration passed, there is a header() redirect to a login or main page. That header function would fail if ANY content had been sent to the browser - even if it was just the opening "<HTML>" tag or a line-break before the opening PHP tag.
  2. There is no built-in function/methods that I am aware of. But, the process of getting the data would be a very simple process. function getDOWs($year, $month) { $monthDays = array(); //Output variable $daysInMonthy = date('t', strtotime("{$year}-{$month}-01")); //# days in selected month for($day=1; $day<=$daysInMonthy; $day++) { //Create timestamp for current day of month $date = strtotime("{$year}-{$month}-{$day}"); //Add numeric day of month and the doy of week name to output array $monthDays[$day] = date('l', $date); } //Return results return $monthDays; } echo "<pre>"; print_r(getDOWs(2015, 9)); echo "<pre>"; Output for 2015 and 10 Array ( [1] => Tuesday [2] => Wednesday [3] => Thursday [4] => Friday [5] => Saturday [6] => Sunday [7] => Monday [8] => Tuesday [9] => Wednesday [10] => Thursday [11] => Friday [12] => Saturday [13] => Sunday [14] => Monday [15] => Tuesday [16] => Wednesday [17] => Thursday [18] => Friday [19] => Saturday [20] => Sunday [21] => Monday [22] => Tuesday [23] => Wednesday [24] => Thursday [25] => Friday [26] => Saturday [27] => Sunday [28] => Monday [29] => Tuesday [30] => Wednesday )
  3. interesting, since the example on the page you linked seems to highly infer that the 'name' is the document name $("button").click(function(){ $("#table2excel").table2excel({ // exclude CSS class exclude: ".noExl", name: "Excel Document Name" }); });
  4. A few responses are referring to "encryption" above. Hashing is not encryption, but it is routinely called that. Since you are specifically asking what hashing is, I think it is important to differentiate the two. Encryption is used when you need to securely store a value which you will need in its original state in the future. For example, if you allow the user to store thier credit card number for the purpose of easy check outs in the future, you would need to encrypt it. Other data such as SSNs, birth dates and other PII data should be encrypted as well (assuming it shoudl even be something to be stored). With encryption, there is a key or some method to decrypt the value back to its original state. Hashing is used to verify that some value is the same as some other previous value. hashes cannot be decrypted back to their original values. Two specific uses for hashes are for password and file verification. When a user creates a password, the hashes values should be stored - not the actual password. Then, when logging in, the user submits their password and the value will be hashed in the same manner in which is was when stored. Those hashed values are then compared to see if the user entered the correct password. Passwords should be hashed because people use the same passwords on different sites. If the database is compromised, the malicious user already has all the data. But, we want to prevent them from getting the original password. Hashes are also used for file verification. If an install file for some shareware app is made available for download from many sites, you want to be careful to ensure you are getting the "real" file and not one that has been modified with malicious code. The author may provide a hash value of their file. Then when you download the file from an alternative site you can run a hash on it to ensure it returns the same hash and has not been modified. Hashing is also referred to one-way encryption because, ideally, you should not be able to decrypt it since it is used for comparing two value. But, you may hear about being able to decrypt hashes via rainbow tables. It is not really decrypting. A rainbow table is the process of generating hashes for MANY different values (typically a dictionary list). If I hash the word "password", it will be the same hash every time (assuming no additional processes are used). So, if a programmer just used a simple hashing method, I could create hashes for common words that are used as passwords and find the users that are using those words since they would have the same hash. But, a hash should not be used on its own. When hashing a value a 'salt' should be used to ensure the hash is unique for that user/record. For example, if you were to concatenate the user's password and the timestamp of when they registered before hashing you would have to create a rainbow table specific for each user. The password_hash() function specified above has this built in.
  5. Um, yeah. I don't think you are going to get someone to parse through all of that code to try and figure out the problem. It seems you are simply checking a session value to determine whether registration succeeded or not if($_SESSION['regsuccess']){ But, the code has some logic problems. take this for example: else if(isset($_SESSION['regsuccess'])){ /* Registration was successful */ if($_SESSION['regsuccess']){ There is an elseif() to check if that variable exists. Then there is an immediate if() condition after that to check the same exact thing. That is not the cause of the problem you are experiencing - but it shows that the logic is flawed and that there are likely bigger issues. I think you first need to go back and map out the logic on a piece of paper or in a flowchart. Then revise your code for that logical workflow. As to knowing why registration fails. You need to look at all the conditions that would cause the value to not be set. Add error handling to log the errors some way. That way you can find out "why" the registration failed.
  6. JayDz, Your request and follow up comments are not very specific and are leading to confusion. The reasons the others were suggesting adding a unique constraint to the table is they are under the assumption that you don't want "duplicate" records to begin with. But, I don't think we are really talking about duplicates. The way I understand it is you have a table that logs when users log in and you want to remove old records for users instead of maintaining a history. So, I will ask a different question. Do you only want one record for each user to record the last successful login for each user? Or do you need to maintain some prior login records: e.g. a certain number or however many going back a certain number of days? If you only want to maintain one record for each user, then you do not need (or want) to implement a process to remove "duplicate" records. Instead, you would just do an "INSERT ON DUPLICATE KEY" query. That will either add a new record if one doesn't exist for the user or, if there is an existing record, it will overwrite it with the new data. That way you have just one query to insert/update the records in the table and there is no need for any secondary process to delete records. If you want something along the lines of the other scenarios I mentioned there are better solutions than what you are asking. So, please describe what the purpose is of the table and what you are trying to accomplish in plain English rather than providing specifics of the mechanics that you think you want to accomplish.
  7. Barand may come up with something more efficient. But, give this a try: SELECT p.ProspectID, p.ProspectName, p.ProspectCode, p.ProspectStatus, n.NoteID, n.Note FROM Prospects p LEFT JOIN Notes n ON p.ProspectID = n.NoteProspectID AND n.NoteID IN ( SELECT MAX(NoteID) FROM Notes GROUP BY NoteProspectID ) WHERE p.ProspectCode = “123abc” AND p.ProspectStatus = “Contacted”
  8. That page would also 'fail' because you are outputting content to the page and THEN attempting to use a header redirect - which I already stated twice is not valid.
  9. gizmola, My point is that it does not generate a notice when used within a double quoted string. The manual does discourage leaving the quotes off non-numeric keys in most circumstances - as you stated. But, within a double quoted string it is proper and valid to leave them off per the manual. error_reporting(-1); $foo['bar'] = 'output'; echo $foo[bar]; echo "<br><br>"; echo "$foo[bar]"; The output of the above is No notice for the instance where the array key has no quote marks when used within a double quoted string. It is my opinion that making one instance valid and another not is a bad idea. I would suggest the second instance should generate a notice.
  10. There's also this from another page in the manual: http://php.net/manual/en/language.types.array.php
  11. @gizmola, I (almost) always wrap my variables in curly braces when used in a string. However, I think the problem with people not using quotes around strings used as array keys is specifically because there is a specific exception with regard to the use of array variables in double-quoted strings. As you point out, this will not work: $name['first'] = 'Fred'; $name['last'] = 'Stone'; $output = "Hi $name['first']! I hope that you and the rest of the $name['last'] family have a great visit with us at our first class resort!"; echo $output; However, this will work and is actually 'proper' per the manual (see third echo in example # $name['first'] = 'Fred'; $name['last'] = 'Stone'; $output = "Hi $name[first]! I hope that you and the rest of the $name[last] family have a great visit with us at our first class resort!"; echo $output; Note: single quotes around the keys when defining, but no quotes around the keys when used in double-quoted text. Personally, I don't like it and never use it.
  12. A page cannot output content to the page (even the tags that start the page: <html>, <head>, etc.) and then use a header command (such as a redirect).
  13. Why are you going to output content to the page AND THEN also have a redirect at the end (which will fail anyway since you've already output content to the page).? But, you don't need to do TWO queries. Just run the ONE update query since it already has the same condition as the first query. So the record would only be updated if meets the criteria anyway.
  14. Your explanation isn't very clear. It might help to show some sample data in those two tables and the expected results from the query.
  15. Ch0cu3r meant to say "storing whether each member is subscribed or not in separate text files is very inefficient."
  16. Well, you are using an INNER JOIN (or just JOIN) in a way by including both tables and using this in your WHERE clause WHERE o.orders_resellers_id = r.resellers_id Personally, I never use that type of construct to get data from associated tables. I would always use a proper JOIN for many reasons. For one it makes the criteria for associating the records much more apparent. Plus there are many features you can't use without a proper JOIN. Your original query would work the same as this FROM orders AS o JOIN r.resellers AS r ON o.orders_resellers_id = r.resellers_id The normal JOIN will return a result set for all records where a JOIN can be made. In this case, if there are any records in orders that does not have at least one corresponding record in resellers OR if there are any records in resellers that do not have a corresponding record in orders they will not be returned. In this case, you want ALL the records from the orders table even if there are no records in the resellers table. Based on the current query structure you would use a LEFT JOIN. That means return ALL matching records from the LEFT table (i.e. first table - orders) and JOIN any matching records from the right table (resellers). $sql = "SELECT o.orders_id, o.cust_order_id, o.cust_company, o.due_date, o.product, o.quantity, o.price, o.requirements, o.cust_order_total, o.order_status, o.reseller_earnings, o.orders_resellers_id, r.reseller_name, r.reseller_surname FROM orders AS o LEFT JOIN resellers as r ON o.orders_resellers_id = r.resellers_id ORDER BY due_date DESC";​ Take a look at this page for some examples of JOIN types: http://www.sitepoint.com/understanding-sql-joins-mysql-database/ Also, I see you named the foreign key in the orders table as "o.orders_resellers_id". I would suggest naming it "o.resellers_id" - exactly the same as it is in the resellers table. That makes it explicit that it is a primary/foreign key in those two tables. Plus, as stated previously, there are some features where using the same name simplifies the logic: e.g. USING(). You could use this for example FROM orders AS o LEFT JOIN resellers as r USING(resellers_id)
  17. I would create an index.php file that is used for all the requests. That file would have something like this at the top session_start(); //Check if family data is already set in session if(!isset($_SESSION['family'])) { //Set the default data include('setDefaultData.php'); } The setDefaultData.php page would have the initial data to set in the session. Something like this $family = array( //Include all the associative array data to set for the default ); $_SESSION['family'] = $family; As for how I would do it, I am the wrong person to ask. I don't have a formal education in programming and your instructor is looking for the use of specific design patterns.
  18. Regarding the data, it doesn't state if the data needs to persist across sessions. You could just create an associative array (or arrays) with the starting state of all the data. Then on the first page load check to see if that data exists in the session. If not, load the initial data. Then on each subsequent page load use the session data. Then, whatever functionality you have will manipulate the session data. If you closed your browser and go back, you would start with the initial seed data. This is a good approach for an activity such as this for several reasons. You can create specific use cases that start with the initial data. As you test, if a problem is found you can modify the code and start the user cases over from the beginning. If you were to use a database you would likely need to reset it to default data anyway. As for the classes to you - that is up to you. How it should ideally be set up for this exercise would likely be predicated on any lessons you've already had in the class as lessons are typically designed to build upon the previous lessons.
  19. When you say "on click" that typically means using the onClick event in JavaScript. But, based on your explanation, it could just as easily be accomplished with a normal HTML form. But, those are just two methods to initiate the action (i.e. make a call to the server). So, you can either use a traditional HTML form or use an onClick event to make an AJAX call. I would suggest starting with an HTML form to get a working solution, then you can add an onClick event to initiate if you need to perform it without a page refresh. I assume you would have a form with all the relevant files listed and perhaps checkboxes to indicate which files to be moved. You would submit that form to the processing page (PHP) which would take the form data with the list of files and perform a move operation on them. However, allowing user input to be used to perform low level file operations can be risky. You will need to ensure that all input is validated and ensure no malicious references are sent from the user. That is a very high level generalization. If you want more specific help, you will need to provide the specific part that you are stuck on.
  20. Just to add to cyberRobot's response. If you reference the values in the result set in an associative array, there can only be 'one' value for any specific key in the array. So, you either need to alias different fields that use the same name or you can reference the data with a numerically based index. I would go with the former as cyberRobot suggests. Also, if you have such a problem, that might be an indication that you need to use more unique names (e.g. order_id & resellers_id). This way, you can use the same field name as the primary key in one table and the foreign key in another. It may seem more "wordy" and superfluous, but your queries will be much easier to read when you have many JOINs. Also, there are some MySQL functions that you can't use otherwise, such as USING()
  21. AJAX makes sense in this situation because the other solution would require duplicate logic to be crated in JavaScript. That only makes things more difficult and error prone. Since you already have to create server-side code to do the calculation, you can just use AJAX (JavaScript that would call the server-side code) to get the same results. That way you only need to write the logic one-time and then re-purpose it for multiple uses (one to provide immediate feedback to the user and two to do the official calculation when processing the order). But, if the problem was about validating that a required field had a value it might be easier to write separate logic for server-side and client-side. As for how to implement AJAX, that is beyond the scope of a forum post. but, JQuery makes it very simple. Here is how I would implement it: 1. Create a file with a function to perform the calculations based on data passed to it. Typically this would be a list of products and quantities. The logic would look up the prices from the DB and do the multiplication and addition to get the subtotal. Then there might be additional logic around shipping or, in this case, comissions. The function would return the results. 2. The page that receives the form POST will process the data into the format expected by the function and then get the total for use in creating the order records. 3. Create another page to receive the AJAX request. That page would only need to format the POST data to send to the function and get the total. Then that page would return the total to the calling AJAX function 4. Create a trigger on the page to get the total (without the user actually submitting the order). The trigger would call a JavaScript function to send the relevant form field data to the page on #3 above.
  22. You should NEVER rely on JavaScript (or anything client-side) for any business logic as it is very simple for a user to circumvent and pass whatever data they want. For example, if you have a select list of valid values for a particular field, you cannot assume that other values will not be passed. A malicious user can easily inject any value they want - regardless of what is in the select list. As to the above, if you were to rely on calculations made on the client-side to be used for the actual billing/charging of the customer, a malicious user could manipulate the values to anything they want. That is not to say that you can't add business logic to client-side code to provide the user a better experience. You just can't rely upon it. So, you would first want to ensure you have all business logic implemented on the server-side. Then, you can add logic on the client-side where it makes sense. For example, let's say you have a field for an email address and you want to validate that the format of the value matches what an email address should look like. You would add logic on the server to check the format and throw an appropriate error if found to be invalid. But, maybe you don't want to have the user POST the page before finding out such an error exists. You could then add additional client-side logic to check the email address when the user exist the field or when they attempt to POST. So, going back to the calculation. As stated above, you absolutely want to have server-side logic to do the calculations when it comes to billing/charging. If you want to give the user some immediate feedback, you could ad​d client-side logic to do the same calculation. But, that can be a problem as you would have to ensure the two processes are in sync. Otherwise, you risk the displayed (client-side) value not matching what the user is ultimately charged. A better approach would be to write the logic one-time on the server-side. That process could be used for both the final calculation when the order is submitted and you could use it within an AJAX call to provide the user a total without having to POST the page. Just don't get that total to display in the client and populate a field for the purpose of using it when the user submits the page as they can change it (even if it is a read-only field). You will want to call the same logic to calculate the price when the order is submitted.
  23. Wow. You must have a very interesting interview process.
  24. You do order calculations on the client-side? Let me know what you are selling and I'll go buy mass quantities and 'hack' the price to be $0.01 I'm not sure what 'earnings' have to do with an order. But, if there are properties of the reseller (which can change) that affect the order, then that is data that is order specific and should be copied to the order as you say you are. Or, you can keep a historical record of those properties of the seller and reference the correct dataset when an order is placed. But, I don't know where this discussion started. If this is a response to my third point - my comments still stand. You are grouping the records to get the total which would prevent the data for those fields to be worthless. Then you can change the LEFT JOIN to a normal JOIN and those resellers without any matching records in the orders table will not be in the result set Then you don't need to SELECT the fields from the order table nor do you need to do the SUM() function (unless it is possible for orders to have a zero value for the reseller earning. If that is the case, then you would need the sum and the WHERE clause could exclude the records with a zero SUM value. And with respect to Barand's last post. If you are wanting all orders rom a specific date to today, then why not just use WHERE orders.due_date >= '2014-01-01' As he said, there shouldn't be any orders in the future.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.