Psycho
-
Posts
12,157 -
Joined
-
Last visited
-
Days Won
129
Everything posted by Psycho
-
I'm pretty sure the "visibility: hidden" CSS property will leave the element in the DOM as well as the page will still act as if the element is there. Whereas the "display" attribute removes the element. (or maybe I have those backwards). In any event, I was curious as to how opacity = 0 would differ from visibility = none. For example, I wondered if text could be selected on the page, if it would print, etc. I've found that for opacity=0 and visibility=none the output (mostly) looks and behaves similarly. In both instances the hidden content takes up the space as if it was displayed. However, there is a difference. You CAN select the content that is hidden using opacity=0 whereas the content hidden using the visibility=hidden you cannot. There is one caveat though. You can't select part of that content, you have to select a visible element before and after the content using opacity=0 and the hidden content will also be selected (confirmed via a Copy\Paste). Here's the code I used to test with Display None: [<span style="display: none;">DisplayNone</span>]<br> Visibility Hidden: [<span style="visibility: hidden;">VisibilityHidden</span>]<br> Opacity 0: [<span style="opacity: 0;">Opacity0</span>]<br> Opacity .5: [<span style="opacity: .5;">Opacity.5</span>]<br> I'm not sure I see a definitive use for one vs. the other unless you believe that the user selecting the page content is a legitimate scenario. In which case you would want to use the appropriate style based on whether you wanted them to copy that content or not.
-
Um, you linked to this post. I'm guessing that was a mistake.
-
No disrespect to @maxxd, but there are some details not covered 1. Since OP did not mention if JQuery is being used, I will point that out. The JQuery library will need to be included (if not already) if you want to use JQuery code (which is a good idea to learn anyway) 2. The on() handler requires that the elements have already been initialized before that code is loaded in order to be applied. So, the code would need to be wrapped in a $(document).ready() handler or something similar. 3. The use of opacity seems odd to me. From a CSS perspective the hidden or display attributes would seem more logical options. But, if JQuery is being used there are the built in hide() and show() methods. 4. The biggest issue is that code will only display the element when loc5 is selected. I have to assume that when the user selects any other value the element should go back to being hidden. 5. Lastly, since the values that hide the element can change over time, rather than setting a default display value in CSS and assuming that the initial value will always use that style, I think it would be better to have the change function executed onload. That way if the initial value is one that should be hidden or shown it will be taken care of. For example, if the form is being used to edit an existing record and that record has a value of 5, then the initial state of the 2nd select list should be to be displayed. Here is a fully functioning example script <!DOCTYPE html> <html> <head> <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.12.2/jquery.min.js"></script> <script> $(document).ready(function(){ //Create event handler for onchange event $('#location').on('change',function(){ //Array of values that should hide 2nd element var hiddenVals = ['loc5']; //Change hide/show status of 2nd element if(jQuery.inArray( $(this).val(), hiddenVals ) != -1) { $('#second').show(); } else { $('#second').hide(); } }); //Run event handler on page load $('#location').change(); }); </script> </head> <body> <select id="location" name="drop"> <option value="loc1">Location 1</option> <option value="loc2">Location 2</option> <option value="loc3">Location 3</option> <option value="loc4">Location 4</option> <option value="loc5">Location 5</option> <option value="loc6">Location 6</option> <option value="loc7">Location 7</option> </select> <select id="second" name="term"> <option value="OPT1">Option 1</option> <option value="OPT2">Option 2</option> <option value="OPT3">Option 3</option> <option value="OPT4">Option 4</option> </select> </body> </html>
-
I don't think you read Kicken's response - at least not correctly. In your DATABASE TABLE, you need a field for the time a record is submitted. The field should be a TIMESTAMP field type with a default value of CURRENT_TIMESTAMP. Then, whenever a new record is created, the current timestamp will be populated int he field for that record without having to include any logic in the INSERT query. Then, when you retrieve records you would use that timestamp to determine whether to display the contents or not. You could just query the records that are more than two days old, as Kicken suggests, but I would expect that if a user has submitted a record that the page should let them see that. So, I would query for the record for the user. If none exists, tell them that. If one does exist, check the timestamp. If the timestamp is less than 2 days old, then show a message that their submission is being processed. Else, show the content.
-
Not really. As I stated above, the target for the form already has arguments on the URL and since the method is GET the intent is for the form fields to be appended to the target URL. Of course, you didn't have any form fields, but the scenario does not have strait forward solution. Based on my reading of the official specs for the form method of GET it is ambiguous as to what should exactly happen If the browser was to render the URL exactly to that definition it would be a malformed URL. Example: <form action="http://domain.com/somepage.php?foo=1" method="get"> <input type="text" name="bar" value="2"> If that code was posted and the full URL was compiled per the specs it would end up as domain.com/somepage.php?foo=1?bar=2 So, the application processing the form needs to detect that there is already a question mark in the defined target and make a decision. Either 1) Remove the existing data after the existing question mark and append the form field data or 2) Append the form field data to the full target URL using a plus sign.
-
Have you used var_dump() on $_POST and $_GET to see exactly what is sent? I don't use Apple products, so I can't be sure, but I'm guessing that either the phone OS or the email client on the phone may be filtering the parameters. Most email programs will not show images by default because spammers can attach different parameters (or use slightly different URLs) to the image URL to individually identify which users have opened the emails. Perhaps the behavior you are experiencing is some sort of similar implementation to protect users. Then again, since the method is GET, the intent would be for any form fields to be included in the URL - but you have already included variables in the URL via the action parameter. Perhaps that is causing some confusion in how the form is handled in the email. Why not change the method to POST. There are not fields in the form, so the variables in the action parameter would still be accessed via GET anyway.
-
On the subdomain.domain.com page you've posted above, the code within the if condition ends with the comment // do login I'm assuming there is more code there that you left out for posting purposes. But, what exactly does that code do? Is there an exit or redirect at the end? If not, then the code will proceed on after the code block and display the login form. But, assuming that the rest of that code is perfectly fine, then your problem is likely that the condition check to see if there was a submission is not returning true. Try putting this at the beginning of that page and see what is displayed to verify what data is passed/ received. var_dump($_REQUEST); exit(); Of course, after I just typed all of that, I think I see your problem: $username = $_REQUEST['username ']; There is a space at the end of the array index name - so there is no username for the code to access. This tells me that the logic to perform the login is faulty and is not reporting an error when no username is supplied (either unset or empty). And here's another possible problem: if(isset($_POST['Submit']) && $_POST['Submit'] == "Secure_Login") The code is looking for a variable with the name Submit. However, your form uses a submit button not an input field with a type of submit. I didn't think buttons passed values. But, you shouldn't use the submit button to check if a form was posted anyway. You can check the $_SESSION['REQUEST_METHOD'] to see if a form was POSTed
-
1. This HTML is messed up. The Child UL element is NOT within an LI element. 2. The width of 30% for the nav container causes the parent links to wrap if the page width is not big enough (which will cause further problem with the 'dropdown' child elements). I set it at a fixed 500px to prevent problems in my test code - change to whatever works for you 3. The padding of 50px seems to be excessive. I think that was a mistake. I changed it to 5px Here is your same code with fixes for the above issues. I stripped out all the unrelated elements <html> <head> <style type="text/css"> nav { padding-top:2%; width:500px; height:27px; margin-left:auto; margin-right:auto; } nav ul { list-style-type:none; } nav li { float: left; } nav > ul li a { padding-left: 5px; } nav > ul > li:hover > ul { display:block; } nav > ul > li > ul { display:none; position:absolute; } </style> </head> <body> <header> <nav> <ul> <li><a href="#">Home</a></li> <li><a href="#">About Us</a> <ul> <li><a href="#">Agents</a></li> <li><a href="#">Locations</a></li> </ul> </li> <li><a href="#">Services</a></li> <li><a href="services.php" tabindex="3" accesskey="S">Services</a></li> <li><a href="quote.php" tabindex="4" accesskey="Q">Get A Quote</a></li> <li><a href="contact.php" tabindex="5" accesskey="C">Contact</a></li> </ul> </nav> </header> </body> </html>
-
Requesting multiple data requests in a single REST request
Psycho replied to NotionCommotion's topic in PHP Coding Help
If I am understading the question correctly, I would suggest returning the data in a multi-dimensional array (in JSON or whatever format you want to use) E.g. Sent: {"item":"a", "limit":123} Received: {"john":{"MIN":4,"MAX",18,"SUM",140},"Mary":{"MIN":6,"MAX",12,"SUM",120}} The back-end query would run this $sql="SELECT name, MIN($item) as minVal, MAX($item) as maxVal, SUM($item) as sumVal FROM my_table WHERE $limit<123 GROUP BY name"; . . . or maybe I am not understanding the issue. -
Chrisj, the code you posted is only for the FORM which the user will interact with to send data to the server. So, "yes" to your first question you can add an option like you have shown. But, that is only half of the problem. Somewhere within the "search.php" page (or other code that is included on that page) there is logic to use the data sent by the user. There will be some code that takes the value of $_GET['type'] and uses it to query for the right records. What he provided is only an example as we have no clue how that logic is currently built. You will need to figure that out or at least provide us the relevant code. Look in the "search.php" file for a reference to $_GET['type'] and a query to retrieve the records.
-
So, instead of asking for clarification on the response you were given in another forum, you decided to ask the same question on a different forum. But, I will give you this advice: $username=$_SESSION['username']; $sql=mysql_query("SELECT student_name FROM register WHERE student_username='$username'"); $ee=mysql_fetch_array($sql); ?> <i class="fa fa-folder-open"></i><b> Hello ! </b>Welcome Back <b><?php echo $ee['student_name']; ?> </b> If you want to display the student_name on every/most page(s), then you should be storing that in the session data so you don't need to do a query just to show that data.
-
I wasn't implying you didn't know how to use Google. I didn't know what the problem was at first. What I was trying to highlight was that the key was to identify the source of the problem. It was only by adding additional elements (in this case borders) that allowed me to clearly see what the cause was. Only then was I able to do a Google search with the appropriate terms. As for that properly not being fully supported, I'm not sure how accurate the data is on that page. I "fixed" the issue using that property and tested it in a Chrome browser. But, according to that linked page the property isn't supported in Chrome. I'd suggest testing it on the current versions of the main browsers. The only other solution that comes to mind right now would be to put each anchor within a DIV/SPAN with properties so they won't split across columns. It may take some trial and error.
-
I had no clue that such a CSS property even existed. I just implemented good debugging skills to identify the problem. Then used Google to find a solution. Being a good programmer is not about remembering everything - it's about being able to find a solution. FYI: To identify the problem I put a border around the outside div and a different color border around the anchor tags. When doing that, I was able to "see" what was happening with the rendered content as the page was re-sized. Then I simply did a Google search for "Prevent text breaking across columns". The very first result gave me the answer.
-
It should not be used for password hashing or for verifying data integrity - with respect to potentialy malicious data. MD5 still has legitimate uses and the fact that it is fast is actually a benefit. I have used it many times for various applications: - Checking for duplicate files or if the contents of files have changed - When creating a service that receives data that has complex actions to be performed, I might store an MD5 has on the original data. Then on subsequent receipts check to see if the same data has been received previously (based on the hash). If so, take no action. Otherwise process the data as needed. - Used as a key or token generator It's all about using the right tool for the job. It just so happens that MD5 is no longer the right tool for some jobs. But, it is still regularly mentioned for password hashing in tutorials and forums. So, just saying "don't use it" is the easier approach to help stop that behavior.
-
There are two aspects that cause this problem: 1) As the page gets thinner, so do the columns. When that happens the records with the longer names no longer fit into a column. Before you filter the records, if you make the page narrower, the record "Fiona Joy (aka Fiona Joy Hawkins)" won't fit on a single line and has a line break. However, it stays in the same column only because the columns are so long. If it was the record at the end of the column, it could very well be in two columns. 2) Once the page is filtered with just the long records - if the record needs to break across several lines due to a narrow page, the following lines of text will naturally flow to the next column. Within the artist.css file, find the definition for "#artist_page .artist_full_list a" and add an entry for the "break-inside" property #artist_page .artist_full_list a { display: block; padding: 4px; break-inside: avoid-column; /* ADD THIS */ /*margin: 0 10px 2px 0;*/ } That should make sure that the anchor tags do not flow across multiple columns. It worked on a test page from your code, but I didn't try a lot of different configurations in data.
-
I assume you didn't really mean to hash the last name $lname = md5(mysql_real_escape_string($_POST['lname'])); Just to be clear: MD5 was only "cracked" with respect to collisions. For example, one use for a hash is to provide a hash for a file so that file can be made available for download from multiple independent sites. by performing a hash on the downloaded file and comparing against the hash from the originator you can be assured that the file you downloaded has not been tampered with. The weakness discovered could allow a malicious user to generate another file in such a way as to generate the same hash. No "crack" exists that makes MD5 more susceptible to preimages - i.e. determining the original value from the hash (although it should not be used for passwords for other reasons - see below). The flaw that does exist with MD5 is that it is fast. Therefore, a malicious user can use a brute force approach to run millions/billions of combinations to try and find "a value" that generates the same hash. There is no 100% certainty that the value found that produces the same hash is the exact same source value, but when dealing whith passwords, it doesn't matter. 1) The logic typically is just looking for a source that ultimately creates the same hash, so it doesn't matter if it is really the same password or not. 2) When dealing with passwords, the min-max lengths and the available character set make the universe of possible values a finite number. It would not be impossible to run every possible combination of values (even for different salts) in a reasonable amount of time. Any hashing method can be brute forced - which is why you want to use a method that is slow; so the time required to go through all possible values would take an extraordinary amount of time. That is why users should use complex passwords. If an attacker has a DB full of hashed passwords, they could simply do a brute force using a dictionary attack of common words to find matches.
-
You should NOT have a way to recover passwords. Passwords should only be able to be reset. If they can be recovered, that means that you have the ability to access their password (even if it is encrypted) - which may be used on different sites. That is a significant security flaw. Passwords should be hashed (with an appropriate salt) sometimes referred to a one-way encryption. Even if your site doesn't contain sensitive information, you have a responsibility to your users to strenuously protect their passwords. Many people use the same passwords in multiple places, so if a hacker was to obtain user credentials from your site, they could try the same credentials on other sites (e.g. banking). Note: Do not try to create your own hashing process. Do your research and find one that is already vetted. If a user forgets their password, they should have to "request" a reset by entering their username or email address. That request will send an email (to the registered email for the user account) with a link to reset their password. The link will contain a token that makes it good only a for a limited amount of time. That link will take them to a page where they can answer their security question(s) and then set a new password. Of course, there always needs to be a way (typically through support) to access an account in edge scenarios: someone left the firm, user no longer has that email address, etc. One other thing. The process to request a reset should not leak information. If the user enters a username or email address that does not exist, the response should be the same as if it did. E.g. "An email has been sent to reset your password". If the email does not exist in your system (user entered the wrong email), you could still send an email to the address stating something like "An attempt was made to reset a password using this email address, but it does not exist in our system". Why do all of that? A malicious user could use your password reset request page to data mine email addresses or user IDs by posting values and checking the responses. At best they may just want to have valid emails to spam. At worst, they may be looking for valid user IDs for the purpose of compromising your application.
-
mac_gyver's response was correct, but you may have missed the point when trying to understand it with complex data. Let me give an example Instead of an array like this array( 'AAA' => ( 'week' => 'week1', 'value' => 'valueA' ) 'AAA' => ( 'week' => 'week2', 'value' => 'valueB' ) 'BBB' => ( 'week' => 'week1', 'value' => 'valueC' ) 'BBB' => ( 'week' => 'week2', 'value' => 'valueD' ) ) It should be like this array( 'AAA' => ( weeks => ( 'week1' => 'valueA', 'week2' => 'valueB' ) ) 'BBB' => ( weeks => ( 'week1' => 'valueC', 'week2' => 'valueD' ) ) ) This can be accomplished by adding some logic to the code that builds the array. I didn't test mac_gyver's solution. It looks like it would work, but I would do it a little differently to make it easier to understand. NOTE: Don't use variable names such as "$array" - give them meaningful names to help you know what they contain and the type of variable. I assume you have a foreach() or some other type of loop, so this may need some tweaking. Other assumptions: 1) The The records are ordered by date. 2) The is that for every employee the same "weeks" exist in the data. If not, some additional logic would be needed. But, this should get you started <?php //Create array to hold the restructured data $payrollAry = array(); //Process the data into a structured array foreach($resultSet as $row) { //If this is the first employee record for this ID, set the top-level array values if(!isset($payrollAry[$row->IdEmployee])) { $payrollAry[$row->IdEmployee] = array( 'name' => $row->employeeName, 'weeks' = array() ); } //Add the weekly data to the sub array (by date) for the current employee $date = date("jS M Y", strtotime($row->Year.'W'.str_pad($row->Week, 2, 0, STR_PAD_LEFT).' +6 days')); $payrollAry[$row->IdEmployee]['weeks'][$date] = "{$row->CurrencySymbol}{$row->Wage}"; } //Create output for the data $wageOutput = ''; //Create the header row output $wageOutput .= "<tr><th> </th>"; //Use the first element in array to get the dates for the header $firstRecord = current($payrollAry); forech($firstRecord['weeks'] as $date => $value) { $wageOutput .= "<th>{$date}</th>"; } $wageOutput .= "</tr>\n"; //Create output for employees foreach($payrollAry as $employeeID => $employeeData) { $wageOutput .= "<tr>\n"; //Add employee name $wageOutput .= "<td>{$employeeData['name']}</td>\n"; //Add employee wages for each week foreach($employeeData['weeks'] as $wages) { $wageOutput .= "<td>{$wages}</td>\n"; } $wageOutput .= "</tr>\n"; } ?>
-
As I stated, the example I provided above works for me as expected. Did you try that example page or are you only trying in on your full page? If you are only trying it on your full page, there's a good possibility that there are some errors in your code. Please try the sample script I provided (if you have not done so already). If the sample page does not work as expected, what browser are you using? Have you tried different browsers. I can't help you when all you tell me is that it doesn't work - when it works correctly for me.
-
FYI: There are a few things you should look into changing. 1. The mysql_ extentions have been deprecated for a long time now. Use mysqli_ or, better yet, PDO for DB operations. 2. Do not use "SELECT *". It may not be an issue in most cases, but it is bad form and could lead to security problems or bugs in some cases if you are not careful. It's always best to list out the fields you want. 3. There's no reason for creating all those temporary variables to get the datetime into the format you want. It's just adding unnecessary overhead. You could just do this: $notedateformat = date("n/j g:ia", strtotime($notesfill['note_date'])); or you could set the format is the SELECT parameters.
-
There is no good solution for this. The browser is doing exactly what it should do. There are some things you can do to achieve what you want, but none are perfect. Here are some things you can do: 1. Use a table. You can try putting the buttons in the TDs and making their height 100%. I tried some variations with buttons and your CSS and didn't get good results. So, you could also use DIVs with an onclick event instead of the buttons 2. Use a fixed height DIV for the text inside the buttons. Use a height that will accommodate the the height needed for the button(s) with the most lines of text. This could be problematic if users have defined larger/smaller text sizes for their displays. 3. Use a fixed height for the buttons that will accommodate the one with the most lines of text. Has the same drawback as #2
-
It works fine for me in Chrome (not tested in other browsers). - If the first field is "Yes" the second field is hidden and not required. I can submit the page without errors/warnings. - If I set the first field to No, then the 2nd field is displayed and IS required. If I attempt to submit w/o making a selection in the 2nd field, the browser displays a warning. If I make a selection in the 2nd field, then I can submit w/o errors/warnings. Here is my full test page <html> <head> <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.12.2/jquery.min.js"></script> <script> $(document).ready(function (){ $("#JOBPRESENT1a").change(function() { if ($(this).val() == "No") { $("#jobfinish").show(); $("#JOBFINISH1a").prop('required', true); }else{ $("#jobfinish").hide(); $("#JOBFINISH1a").prop('required', false); } }); }); </script> </head> <body> <form method="post" action="" id="theform"> <label id='tooltip1'> Are you currently working with this company?<span></span><a>??<span>INFO</span></a></label><br /><br> <select id='JOBPRESENT1a' name='JOBPRESENT1a'><br> <option value='Yes'>Yes</option> <option value='No'>No</option><label> </select><br> <p id="jobfinish" style="display:none;"> <label id='tooltip1'> Which year did you finish working with this company?<span></span><a>??<span>INFO</span></a></label><br /><br> <select id='JOBFINISH1a' name='JOBFINISH1a'><br> <option value=''>Which Year</option> <option value='2020'>2020</option> <option value='2019'>2019</option> <option value='2018'>2018</option> <option value='2017'>2017</option> <option value='2016'>2016</option> <option value='2015'>2015</option> <option value='2014'>2014</option> <option value='2013'>2013</option> <option value='2012'>2012</option> <option value='2011'>2011</option> <option value='2010'>2010</option> <option value='2009'>2009</option> <option value='2008'>2008</option> <option value='2007'>2007</option> <option value='2006'>2006</option> <option value='2005'>2005</option> <option value='2004'>2004</option> <option value='2003'>2003</option> <option value='2002'>2002</option> <option value='2001'>2001</option> <option value='2000'>2000</option> </select><br> </p> <br> <button type="submit">Submit</button> </form> </body> </html>
-
OP: 1. Since the initial value for the 'JOBPRESENT1a' field is yes, remove the required attribute from the 'JOBFINISH1a' field. 2. Change the function to show/hide the 'JOBFINISH1a' field to this $(document).ready(function (){ $("#JOBPRESENT1a").change(function() { if ($(this).val() == "No") { $("#jobfinish").show(); $("#JOBFINISH1a").prop('required', true); }else{ $("#jobfinish").hide(); $("#JOBFINISH1a").prop('required', false); } }); });
-
Ah, thanks. As this was a JS question, I assumed the validation was JS related and didn't look for that.
-
There is nothing in the code you have provided that makes any fields required. The only thing the code you provided does is hide/display the second field. Based on your comments there is some code somewhere to check for required fields. You should have logic that is implemented server-side (i.e. PHP), but you can also add logic client-side (i.e. JavaScript) for usability. You need to provide the code you already have to perform the validation in question in order for us to help. But, on a general level it would probably look something like this if($JOBPRESENT1a=='no' && $JOBFINISH1a=='') { //Error: If you are no longer working for the company, the year you left is required }
