Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Psycho

  1. One other problem I see: It appears there is a single submission_id whether the user submits one or multiple pets (since it is not included in the JSON data). But, the current code is using that submission_id to determine duplicates. If a user was to submit two records. I think you would end up with ONE in the database. The first record submissions would be created as a new record. But, when processing the second submissions, the code would "assume" it was a duplicate because there is an existing record with the same submission_id (i.e. the first record) and it would perform an UPDATE. I'm not sure where/how the submission_id is being created/managed. But, I think you'll need to change that logic.
  2. Maybe I am missing something, but I think there is a simpler solution. The intent appears to be to get a list of IDs that DO NOT match those two conditions. Rather than creating JOINs or Sub-Queries, why not just change the conditions to be a positive check rather than a negative check. So, instead of looking for records that do not match BOTH those conditions, just look for records where either (i.e. OR logical operator) of those conditions are not true by switching the operators from <= to > and the other from >= to <. This should get the same results in a simpler fashion: SELECT RentID FROM rental WHERE Dispatch > "2019-10-08" OR Dropoff < "2019-10-02"
  3. OK, there could be multiple changes needed. SO, I would start by running a test. Edit a record in the DB (change a value of 1 to 1.5) and does that record correctly sort between 1's and 2's on the pages where it is to be sorted? If yes, then you only need to solve the problem of where that value is INSERTed/UPDATed in the database. I don't see any such queries in the code you have provided. Look for any code with queries that do INSERT or UPDATE for and which include the sort field. My guess is you will see something similar to the process I see used in the above queries where p.products_id = '" . (int)$_GET['pID'] . "' But, of course this would be for the sort field. Change "(int)" to "(float)" in those instances. That may be all that is needed. If not, we would want to trace back to where the variable used for that field may be modified before being used in the query.
  4. @Barand I was thinking the same thing - just build the array the way you need it. But, it's also possible that the loops at the top are just to create some mock data as it would be returned from a DB query and the reason he needs a convert() function is to then turn those DB results into a logically structured array. Either solution could have very easily been provided in the very first response if the problem was explained clearly. But, it's impossible to know without consulting the crystal ball 🔮 EDIT: Also, I'm not sure when it changed, but you can define a "child" array element directly w/o having to define the parent elements first. This used to produce a warning, but has not been the case for a long time now. So, while I used to do just as you did above (and sometimes still do), that can be simplified to just this foreach (range('A', 'D') as $section) { for ($row = 1; $row < 3; $row++) { for ($seat = 1; $seat < 4; $seat++) { $srs['sections'][$section]['rows'][$row]['seats'][] = $seat; } } }
  5. Please read that statement back to yourself. I really don't care if someone uses poor grammar or has misspellings - as long as what they are stating is understood. I don't understand that. I *think* you might be stating that the variable $srs is not being recognized in the convert_array() function. If so, why did you not post the error? It will tell you the line number that the error was thrown on. I ran the code you posted and it executed w/o error - but it is not a multi-dimensional array as you last posted. I have the following in the signature of my posts "The quality of the responses received is directly proportional to the quality of the question asked." I find it rather annoying when people come to ask for free help and can't take the time to clearly define what it is they want. I still don't know what you are wanting to achieve. Are you wanting to convert the single-dimensional array to a multi-dimensional array? If so, why don't you create the array as multi-dimensional to begin with? Also, why does each successive for() loop use the ending value from the previous loop as the stating value? I see no logical reason why "Section 1" would have rows 1-5, "Section 2: would have rows 2-6, "Section 3" would have rows 3-7, etc. None of this makes any sense. No. $srs is passed to the convert_array() function which simply returns back the original value passed into it. The use of that function with $srs is used as the parameter for the output() function. The end result is that an array identical to $srs is passed into the output() function - which simply dumps the contents of the array to the screen. I don't see anywhere he is trying reference $srs in the convert_array() function. The code "works" without errors.
  6. Yeah, you need to provide clarification. I';ve read your code and your request and am not sure what you are trying to accomplish. I see that you are creating some "random" records to specify "seat" which include three properties: section, row and seat no. Are you wanting to condense these so you can show a series of seats in the same section/row? E.g. "Section 4, Row 8, Seats 6-10"? Or are you just wanting to output each record in a human readable format: "Section 4, Row 8, Seats 6", "Section 4, Row 8, Seats 7", "Section 4, Row 8, Seats 8", etc.? If it is the former, I would structure the array differently. If the latter, then just loop over the array foreach($arrayVar as $seat) { echo "Section: {$seat['section_name']}, Row: {$seat['row_name']}, Seat: {$seat['seat_name']}<br>"; }
  7. OK, so Google does have a product that you might be able to tie into: Vision AI. I saw in a forum post that there is an enhancement request to detect image orientation, but I don't know if it is implemented yet. It does have face recognition and I would assume that would return a rectangle. So, if there are faces in a photo, the correct orientation should have the long sides of the rectangle(s) be vertical. But, you could inadvertently turn the picture upside down. In any event, trying to explain how to use such a service is beyond the scope of a forum post. Good luck.
  8. OK, let's break this down. You state you want to automatically change the orientation of an image when it is submitted. First of all, I don't see anything in that code related to image submissions. I would expect to see data relate to $_POST/$_FILES arrays on a page that handles submissions. OK, but let's say we have that code. How are you planning to determine the correct orientation to change to automatically? Functionally, it is not 'difficult' to change the orientation of a photo in PHP, but there is no functionality in PHP to "look" at a photo and know how to correct it. What you could do is allow a user to upload a photo and then present the photo back to them so they can determine if the orientation is correct. If not, give them the ability to "fix" it. This could be as simple as providing three buttons: rotate 90, 180, 270 which would just perform that one action OR you could provide some robust javascript front-end tools to 'manipulate' the image on screen and allow them to submit those changes. That would require PHP code to actually implement all the options you allow on the front-end. Here is the PHP manual for the image rotation function. But, as stated above, you have to give the code some way to "know" how to rotate it correctly. I'm sure there are some third party applications (for $$$) that you could implement. Or, Google may have something for free you could tie into to try and determine the correct orientation. But, none of that would be simple.
  9. What you are wanting to do is "spoof" the from address. While there can be some legitimate business needs to do this, it can create problems that are difficult/impossible to resolve. Spoofing the from address is rather simple and is something that spammers/scammers have been doing for many years now. E.g. you might be sent an email from representative@yourbank.com as a phishing attempt. The fact that the from address looks to be a legitimate email from your bank gives the email some credibility. Because of this, there are an array of different protections that can be in place to prevent/hinder this. The crux of the issue is that you want to send an email from "user@usersdomain.com" but it is being sent though your form which is going to send it through the email server that you have configured for your form - in this case gmail.com and using the credentials of a gmail account. Generally, an email should be sent through the SMTP server that is responsible for the domain of the sending user (or through an SMTP server that has been identified as an authoritative server for that domain). You cannot control the authoritative servers for domains you do not own. Then, there can be protections on the receiving end: either in the SMTP servers or in third-party services. When an email comes in the system may do a reverse-lookup to ensure the email came from an authoritative server. If not, it gets dropped. To put it simply, you can try it. It may not work for all emails (especially if they are being sent to different domains) and there is no guarantee that it won't stop working one day because you are performing the same action as a scammer would. Having said all that, when sending an email you can specify the sender information within the headers. Here is an example of the header in a sample script of mine using PHP's mail function (this uses a "friendly" name :in addition to a specified from email address $to = 'recipient@recipientdomain.com'; $subject = "Subject of the email"; $message = "Here is body of the email message"; $headers = 'MIME-Version: 1.0' . "\r\n"; $headers .= 'Content-type: text/html; charset=iso-8859-1' . "\r\n"; //From info $headers .= 'From: Bob Smith <bob.smith@bobsmithsdomain.com>' . "\r\n"; $headers .= 'Reply-To: Bob Smith <bob.smith@bobsmithsdomain.com>' . "\r\n"; $headers .= 'X-Mailer: PHP/' . phpversion(); $message = "Here is the message"; mail($to, $subject, $message, $headers); For your function, I suspect you would do it like this: $headers = array( 'From' => $_POST['EmailAddress'], 'To' => $to, 'Subject' => $subject ); But, for the reasons stated above, I would not advise this. "System" emails should be coming from the system/application. There are other ways to allow the recipient to respond to the requester.
  10. Are the lines to connect to the DB included in this script? They shouldn't be. You should have a single script/file to connect to the DB. That way if there is ever a need to change the connection info for the database server it only has to be done one and in a file that is appropriately named (e.g. connectDb.php). What if you aren't around when the change has to be made? How are they to know all the places where the connection info needs to be changed. If you are already doing that for the most part, you're ahead of where many people are.
  11. I would add one more recommendation. Don't intermix PHP logic and HTML. Put all of your logic at the start of the script and assign the output to variables. Then output those variables int eh applicable areas of the HTML. As you build more complexity you will need to create scripts for specific purpose and include them with other scripts (instead of copy/pasting the same code all over the place). Example <?php //Connect to DB //Execute query $output = ""; while($row = mysqli_fetch_array($sql)) { $output .= //some code to create html output } ?> <html> <body> Here is my output:<br> <?php echo $output; ?> </body> </html>
  12. You are executing the query TWICE. The part in the if() condition isn't checking the results of the first execution - it is executing the query a second time and the if condition is acting based upon the true/false response of that second execution. $stmt = $DBcon->prepare("UPDATE Codes SET UserID = ? WHERE UserID = ? LIMIT ?"); $stmt->bind_param('iii', $subida, $userida, $cra); $stmt->execute(); //FIRST EXECUTION if(!$stmt->execute()) { //SECOND EXECUTION echo "Error: " . mysqli_error($DBcon); }else{ echo "Success adding user : $subida with : $cra "; echo "<meta http-equiv=Refresh content=1;url=Subseller.php?success=1 >"; } You can either execute ONCE within the if() condition or assign the result of the first execution to a variable and check the value of the variable in your if() condition $stmt->bind_param('iii', $subida, $userida, $cra); $result = $stmt->execute(); if(!$result) { echo "Error: " . mysqli_error($DBcon);
  13. I'm definitely considering this. It seems it would be infinitely easier. The linked example you provided helped me visualize it better.
  14. @Barand the "questions" absolutely have different available response values (Boolean, Int, Varchar, etc.). But, if I go with a "normalized" response table where all the values are in a single column, I assumed I would have to make the response column a Varchar type to store a textual representation of whatever the response is. Otherwise, I'm at a loss on how to structure the responses to individual questions when the questions (and possible responses) can be changed. However, I think I've had a mental breakthrough - at least with using the "normalized" data structure. It might help to give an example of how the data will be used. This is for collectors of antique weapons to gather data on particular items to ascertain when specific production methods or properties changed over time or at different manufacturing facilities. A relateable analog of this might be for car production. So, let's say they are interested in Ford vehicles and wanted to know how the paint colors varied year over year at each plant. (Assume that the survey for each car make requires different fields, so the survey for Ford is different from other manufacturers) If I created a specific table just for the Ford vehicles surveys (non-normalized), the query would be something like this: Now, if I needed the same data from the normalized, single results table approach I think it would work like this: Of course, this requires more post-processing of the data in order to use it for reports, graphs, etc. But, I *think* this approach will work: i.e. all selection/filtering of specific submissions will take place within the "result_id IN" subquery and the field selection would be done with the "question_id IN" condition. Thoughts?
  15. Thanks @requinix. Two questions: 1) Your example has a "question_id" with four results for different questions. I assume the first column is supposed to the the result_id (the unique identifier for a user submission of a survey)? 2) You state that "It's still indexable, and the query to search is a little less complicated than the relational one . . . ". How would you query the data if stored in that manner. The example I gave before was just a simple one. This will require more complicated queries to look for trends in the data. E.g. primarily there will be a date field and a location field which will be be used to see how the other values deviate based on the date and location values. If this was a "normal" table (each column is a different field) it would be easy. I know I *can* do it with the first example I gave, it just seem unnecessarily hard. And, I have no clue how I would do it with the example you gave. Any references you can point me to? EDIT: Perhaps it is not that "hard" to do it with the normalized table, but I'm having a hard time conceptualizing how I would query/process the data.
  16. I'm working on a project where a user will be able to create custom "surveys" which other users will fill out. Since the questions in the survey will dynamically created, I would think the *proper* way to construct this would be something like this: Questions table: question_id (PK), survey_id (FK), question_text, etc. User Results: result_id (PK), user_id (FK), date_taken, etc. Data Results table: table: data_result_id (PK), result_id (FK), question_id (FK), response, etc. So, the data for a user's response to a survey might look something like this in the data results table data_result_id | result_id | question_id | response 55 4 22 True 56 4 23 Blue 57 4 24 2 58 4 25 Capricorn So all the data is columnar and each user submission is associated based on the result_id. This is all well and good except . . . I think this would make it difficult to create dynamic reports based on responses. E.g. To do something simple such as get all the surveys where the response to question #2 is blue I would have to do something like this: SELECT * FROM data_results WHERE result_id IN ( SELECT result_id FROM user_results JOIN data_results ON user_results.result_id = data_results.result_id WHERE survey_id = 8 AND question_id = "Blue") Doing more in-depth analysis would get even more complicated. Now, if the results were stored in this format it would be much simpler to create/run dynamic reports: result_id | parent | favorite_color | no_of_cars | zodiac_sign 4 True Blue 2 Capricorn Then, I could run just SELECT * FROM survey1_results WHERE favorite_color = "Blue" But that would require processes that are generally considered bad practice: I would have to dynamical create a result table for each survey and I would have to dynamically add/remove columns from that table when the survey is being created/edited. So, is this an instance where having a process for a user to dynamically create tables/fields is the exception that proves the rule or am I overestimating the complexity of the first solution? Not sure which way to go and don't want to code myself into a corner.
  17. I don't like having side conversations not specific to the thread topic,. But since this appears to be more instructive, I thought I'd respond to this question. There are a multitude of uses for hashes aside from passwords. It all depends on the developer identifying a need and implementing it. Basically any time you need to compare complex data. Here are a couple examples: 1. File comparison. For example, let's say you have an application that picks up a file every hour for processing. The file gets written regularly from some process outside of your application. BUT, even though it gets written regularly, it may not have any new data. I might store a hash when I process the file. Then, every hour I will run a hash on the current file contents. If the hash is the same, then I don't process it. There are many use cases where file comparison is needed and where hashing will fill that need. 2. Creating a unique key. In a mp3/music app I worked on, I needed to quickly look for duplicates based on a combination of multiple meta data fields before I inserted new records into the database. Since I was dealing with raw "text" values from the files being process I had not yet determine the unique IDs for some of that meta data. So, I could not use a unique constrain on a single table and it would require a query with multiple JOINs in order to check for a duplicate - on every MP3 file. The processing was executing against hundreds/thousands of files, so I wanted an efficient process. In order to simplify this process, I just created a unique key using a hash on the multiple values and could just check that value against a single table in the DB.
  18. Sorry, but I am still not clear. If the messages are all supposed to be "consumed" as a conversation (i.e. user open the conversation not individual messages), then this is the wrong DB structure. Also, your UI example shows each message as a separate record. If it is to be consumed as a conversation, there should only be one record in the UI (with the original title) and when opened, will show the entire conversation. That UI looks like there are three messages with 2 replies each - very confusing. You state the messages will all have the same title - but they don't. The replies all have "RE:". Based on my understanding, you should have one table for each conversation with at least Conversation ID & Title. Then in the PM table, remove the title field and the parent_id will reference the conversation ID.
  19. Not knowing how you are putting it all together, that's a very generic request. I would start by saying you could format your SQL queries for better readability. It helps when looking at a query to easily "see" what's going on. As to your problem, I don't think that last query is correct. The sub-query for the replies has no filter to limit to only the messages respective the the outer conversation. It is difficult from your posts to exactly understand what you are trying to do. It sounds as if you are wanting to get a single record for "conversation" (i.e. the parent_id is the same) that a user has received messages where any of those messages are unread. Further, I think you want the timestamp of the last unread message (to the user) in that conversation. But, what do you want for the title since the title can change? Do you want the title of the parent or the title of the last unread message to the user? note that I assume that a user can read later messages w/o reading all the earlier ones. So, the last unread message is not, necessarily, the last message in that conversation. Also, I'm not sure if the count should be all the messages to the user in that conversation or only the count of unread messages. I think there are problems in the last query you submitted, but I can't say w/o understanding what you are trying to achieve. Perhaps you can supply some sample data and an expected output.
  20. FYI: if("0") will always return FALSE. Although it is a unique case due to PHP being a "loosely" typed language. The integer 0 is FALSE in most/all languages and a string value is normally TRUE. In this case it is a string value with the zero character. Because PHP doesn't have strong distinction between variable types it interprets the string "0" as the integer 0 and is therefore FALSE More info here: https://www.php.net/manual/en/language.types.boolean.php
  21. As others have alluded to it all depends on the content source to be hashed and, most importantly, the purpose for the hash. For example, some people may say to never use MD5 because it has been compromised. While it should not be used for passwords, it is perfectly acceptable and even preferred for some purposes. So, there is no way to appropriately answer your question as it is too general. Sort of like answering what is the best automobile.
  22. Correct, the typical Click Here to confirm your account (in the case of #1). Here's a page on his site where he announced the training module on Pluralsight. He has a mock conversation between himself and a developer creating an account management system. It is a pretty entertaining read. However, Pluralsight is a paid resource. You can register for free and get a free trial of all their contentl. Not sure if a CC is required.
  23. OK, I need to correct myself I was mixing up some of the techniques. I went back and reviewed a training session about account management on Pluralsight (great training material). Troy Hunt (the author) recommends the following approach to prevent account enumeration: Upon submitting a form to register an account provide the user a common message along the lines of "Your registration has been processed, an email has been sent to complete your account". They would get this message in the case of a successful registration or a duplicate username/email. 1. If the registration was successful, the user receives an email to confirm the account 2. If there was a duplicate, send an email to the user that the account was already registered. Of course, this requires a more complicated process of user registration.
  24. Agreed, you should let the user keep trying to register until eventually, in desperation, they try a different user name. At that point, when it works, they realize that the problem was a duplicate username. But at least, you didn't tell them. Just to add some clarity here. @benanamen is correct in that you don't want to create a system that allows a malicious user to easily ascertain usernames from your system - specifically in mass. And, @Barand is correct that it makes no sense on a registration page to NOT tell a user you could not create their account because they chose a user ID that is already in use. The problem to solve is to prevent a malicious user from farming the system to create an inventory of all your users through automation. The malicious users could then iterate through all the users trying different common passwords until they get a match. If this is important, there are various solutions that can be employed: 1. CAPTCHA or some other means that requires human interaction 2. Slow them down. Introduce a delay of a few seconds or more in the registration process which would make the time to get a full list lengthy even with automation. Easy to implement and would not be noticed by users. (as long as it is not excessive) 3. Keep a log of requests by IP, session, or some other means. If those attempts exceed a threshold you set then either prevent new requests or introduce an even longer delay. More difficult to implement. There are other ways (such as using analytics) to programatically detect malicious submissions. But, you need to determine the risks to your application and the costs associated with any potential data breach in order to weight how much effort to invest. EDIT: This is a registration page where a user is creating an account - not an authentication page. You should never tell a user the reason you could not authenticate them (i.e. username not found or password wrong). But, that is not what this was about
  25. I guess you missed the update I posted in response to @requinix It now works for those previous dates as well as the years that end in "00". Tested from year 1 to 3000. I think that should be sufficient. I was really just interested in implementing a calculation to find the day of the week. I think I'll stick with using date() from now on.
  • 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.