Muddy_Funster

I don't use mysqli myself, but as best as I can work it out: ... $mysqli = new mysqli ('host', 'user', 'pwd', 'schema'); $qry = "SELECT $column FROM $table WHERE username = ? limit 1"; $stmt = $mysqli->prepare($qry); $stmt->bind_param('s',$username); $stmt->execute(); ...

@Jaques1 No, now you're twisting things just to be offensive. What I'm saying is that spending weeks coding to protect information that is already publicly available from being made publicly available is a waste of resources. You really do get quite unpleasant on this subject. I know enough about SQL injection attacks that I didn't actually stipulate "SQL" in my post, and I also know that an attack does not have to be able to exploit the "ENTIRE SERVER" to be classed as an SQL injection attack - in fact, I would be really fracking impressed if someone gained root access to an "entire server" from a single injection attack. I get that you have a point to get across, and that you clearly are impassioned by the subject of cyber security, but instead of being so abrasive why don't you try and put your point across in a more civil manner? It will make dialogue more pleasant and in turn make people far more receptive to your point of view. @EricOnAdventure - what @Jacques rightly said is that you should be using mysqli prepared statements It's not quite the same thing. I'm suggesting, apparently incorrectly, that you should code security appropriate to your data. However I am disinclined to offer any further suggestions on this subject as I'm really not having the kind of week where I can be bothered faceless person berate me over the internet.

It goes to a script that replicates the token creation using the email address. e.g for password reset: Hash a token based on UUID, and date now (eg 01/01/1970) Send token to email address. Have link pass email address and token to script Have script create a hash based on the UUID attached to the email address and the current date Compare tokens. If tokens = match present reset form. That's pretty much how I do it. @ Jacques1 : that's not strictly true. The token doesn't contain any human friendly content, there is no way to discern from looking at it what has been used to generate it. It is also sent to the email address of the user, so unless the attacker already has access to the users emails it's redundant. User ID's are not generally available and I also use custom hashing for each process. The target script also looks for a match against a hash generated within it. So to brute force it someone would need to know the UID they want to exploit, the exact hashing algorithm I used and the internal salt string (plus any other data that I may or may not decide to use to build the initial hash depending on my mood at time of coding). Then they would need to recreate the output and push that exactly to the target script. OK, for a web facing product that may not be secure enough - I'm no expert on that, but it more than covers the skill set of the users I cater for. Again, I don't prescribe this approach for a public system, and have little experience of coding for such an environment, I only offer this by way of information, not suggestion. However, I don't see how, if properly designed, there would be nonsense in the table because of transaction volume. It's only a password reset table, I can't envisage that many people needing to reset their password simultaneously as to break a table. Surely a table structure akin to would be a functional transaction table? ||RID||UID||DATE||TOKEN||STATUS||TIMESTAMP_CREATED||TIMESTAMP_UPDATED||UPDATE_COUNT|| From that you can get, regardless of how many people reset their password in a given millisecond, a gauge of how many users reset a password in a given month, how often the 10 most reset passwords were reset over a given time period, if any accounts have requested multiple resets within a time period, how many reset requests on average and/or by max and minimum an account places before converting to a successful password reset. etc. etc.

The answer to questions like this depends a lot on the situation. Is it the most secure way of doing things? No. But, you need to consider how much security is practical and relevant for the data that you are storing. If all you have is a bunch of arbitrary information on people that could easy be gotten just from looking up their facebook link then spending weeks securing your site isn't a productive use of time. I personally don't hold relevant human readable data in the session. I base64 encode relative info - like a pre-hashed user UID token- so that nothing is immediately obvious to people looking at the developer tools that are now included with every browser. I then use this data to pull up related data from the database ad-hock. Using username as your conditional means that anyone that knows another persons username (often visible during login and displayed in account info and the such after it) and knows how to hack the session cookie (not a big challenge these days) could spoof that user directly. That could be a big deal, or it could only let someone access someones real first name and country of residence. It's all relative. For example using variables to define column and table names directly within the query string makes me shudder, but you, and others, are happy enough to do it. I would rather define absolute queries using hundreds of conditionals than throw more variables into a raw query string that I absolutely needed to.

I personally wouldn't store the tokens - any any form - in the DB. For password reset I would have them generated on the fly based on a hash of the account ID, email and date requested. This makes the link valid until midnight server time. For account activation I would do the same without the date part and using a slightly different hashing algorithm. That's just me though, I mainly write internal apps, not open ones. This means I have a more controlled user set so can make decisions based on a narrower group of variables. If you do go down the route of storing the tokens in the DB then you shouldn't really be deleting them, they should be stored in hashed form and flagged with a status. Let the table grow, it can help establish useful metrics on account usage and can be used to flag up suspicious behaviour. You can archive it off on a monthly, quarterly or yearly basis, but I wouldn't throw away data on user activity - not in this day and age.

You just put a conditional check into the loop as it's constructing the option list (assuming you have already dealt with getting the desired value such as 1999) and set the selected attribute when the loop matches the conditional. for($i=$start_year; $i<=$end_year; $i++){ if ($i == $valueFromDB){ echo "<option value='{$i}' selected='selected'>{$i}</option>"; } else{ echo "<option value='{$i}'>{$i}</option>"; } } you could even use a ternary operator to condense the if/else: ($i == $valueFromDB) ? echo "<option value='{$i}' selected='selected'>{$i}</option>" : echo "<option value='{$i}'>{$i}</option>";

Yeah. 100% what @Jacques1 said. You seem to be unaware that everything sent through HTTP Request Method is sent as a string. So you have "20" not 20, "102.99" not 102.99 etc. This isn't usually a problem - as long as you are aware of it so that you can handle the data type as and when you need to. Search the php manual for "typecasting" and you should quickly be able to get some use out of your numbers.

I don't understand what the question is here. Do you only ever want to return users whose first name starts "joh" or do you want it as an option, what are you using to as a data store? what's the issue with scripting the query dependant on the get value? such as : $v = trim($_GET['value']); if($v == ''){ //return full dataset } elseif (is_int((int)$v)){ //return record with ID number } else{ //return results of first name search }

Post up your full (relevant) code, so we can see what you have done so far and what libraries you are linking to.

You shouldn't really have a require_once inside a function - the point of functions is to be re-usable and if you try to re-use a require_once call it's just going to throw warnings up at you. It would be better to require_once your script at the top of the page and then pass the connection object into the function as part of the call.

@benanamen - Just for clarification, comments and suggestions on the use of PDO / mysqli_ over mysql_ were made in abundance in the OP's previous thread (that's how I knew the OP would prefer mysqli_). It's fare to assume going forward that, in the first instance, warnings and recommendations will always be included as part of replies to people seeking assistance with mysql_ and other obsolete code. @Zane - I appreciate what your saying here, but another way to look at it could be: when the OP sees that the "Regulars" (I'm far to self deprecating to include myself under the "Expererts" column) are have a conversation to the nature of the one in this thread - as long as it's kept civil and relevant - it can often encourage them to look into the facts being discussed. So it's kind of like telling them off by proxy. When people see that a bunch of respected coders are having an impassioned debate over aspects of the code they have chosen to use, and it's application in the real world, it can be enough to inspire those that wouldn't otherwise fully investigate the options to go and do so. So if you look at it like that: technically (and kinda indirectly) @benanamen was helping P.S. - probably wouldn't be the worst idea to lock this thread? I'm failing the fight to not post in it and we have drifted off-topic in a more than subtle way .

Yeah, that's not really got the same ring to it though...

And have you checked on every version of every browser on every OS? It's irrelevant anyway - the documentation tells you how to code it properly, and when you do code it properly there are no problems, by that simple fact (and sorry for being blunt) it's not a Mac issue: it's a coding issue.

@requinix - keep us posted on the decision when you have one? @Zane - I obviously don't know as much as you guys, but that flarum forum does look good - particularly like the floating composer for making life easier when referencing code up the page (and the built in @ tagging ofc ) so yeah, I'd be quite happy if you guys wanted to go down that road. The only other way to go -I think- would be something like oxwall (if your at all interested in going down a more "social" kind of route, which given programmers are rarely people persons may well not be a consideration)- but I doubt that the back end supports code integration and if I remember right from when I looked at it a few years ago it's a major pain to customise the source.

You need more faith @benanamen Confucius say: Just because most people don't follow the right path doesn't mean you should shut the gate on everyone that might. (he didn't really, I just made that up - before someone starts an intellectual property suit against me)

You're welcome, just glad to help. Best of luck with the switch over.

Well I don't know about you, but I quite like to know when people are talking about me

Well if you are always taking now as a reference then you can use a php dateTime calculation to work out the duration to the millisecond based on now minus your duration before converting and storing it. However if you are required to store and work with data accurately down to the second you should really be capturing that as part of your input - it's the only way you can get that accuracy.

Hi guys, just wanted to start by saying I'm really glad you are rockin' the new owner gig, I was greatly disappointed when I thought that this resource was gone from the web (though I have to confess I did hope my warning points would have been left on the old servers Now to point - I spend way too much time on twitter and as such have gotten into the habit of referring to people online with the @username handle. Does anyone think it would be a half-way-decent idea if the forum could throw a notification at someone when they are referred to by this (or a custom) method and link back to the post that it was done on? I don't even know if it's practical or possible or if I'm just talking bat guano crazy. Anyway, I thought I would throw it out there, now I'm going to run for cover. LLAP

Wow...deep...completely unhelpful, but deep none the less. Can you explain your current system in a bit more detail? Also, what exactly are you looking to change? Are you in complete control of the back end - including database design? Are you even using a database? We need more information to provide effective suggestions at a solution.

From the little I can determine from the OP they are storing the duration as a direct input. @requinix - that was cruel, and made me giggle.

Well that depends. Could you please give a more detailed description of what the problem actually is?

Glad to hear it, why not post up what you did to fix it and then flag it as answered? That way you will help others who come across your post because of similar issues.

One step at a time. Forcing the OP to change paradigm before offering help will only result in them seeking help elsewhere. Looking up out dated guides that support the obsolete code and getting into a worse position than they are in just now. However, building trust at this point by helping with the problems that are surrounding the obsolete code means that they both get to a position where they are confident to implement the change to PDO (or mysqli; as they have said they will be choosing that route once they are ready) sooner, and also that they will be prepared to come back here for help should they struggle with that change.

Fist of all, compared to most of the regulars on this forum I am a rank amateur, so your praise is somewhat excessive. Now to the issue at hand: You just need to expand the query (and the string assignment) - I altered it to only select the scholarships column from the table as that was the only column you were working with in the previous code, change the query to this: **Change field names as appropriate - I'm guessing as to what TA, RA satisfaction and Rank actually apply to in your HTML table.** $ sql = <<<SQL_QRY SELECT Scholarships AS colorCode, University, Country, satisfaction AS HLStudiesRank, Rank as overallRank, TA AS immigration, RA AS income, FROM {$SETTINGS["data_table"] } WHERE id>0 LIMIT 10 SQL_QRY; and then update the string append in the the while loop to include the other column values: $cTable .= "<tr>"; $cTable .= "<td style=color:{$thisColor['color']}>{$thisColor['word']}</td>"; $cTable .= "<td>{$row['University']}</td>"; $cTable .= "<td>{$row['Country']}</td>"; $cTable .= "<td>{$row['HLStudiesRank']}</td>"; $cTable .= "<td>{$row['overallRank']}</td>"; $cTable .= "<td>{$row['immigration']}</td>"; $cTable .= "<td>{$row['income']}</td>"; $cTable .= "</tr>"; Again, most of this is assumed and will need to be customised for your data.