requinix

Why does something like this need to be in a configuration file? Requiring some specific number of digits is silly, and making that variable seems even sillier. Passwords should contain at least one digit - isn't an option to enforce that sufficient?

Purely random passwords will probably already contain mixed letters, digits, and symbols, so they meet nearly all password requirements already. But surely you recognize that you're in the vast minority of users: a typical person will use a word or two plus a couple numbers as required by the system, and will not have something that creates and remembers passwords for them. Yeah, users may not like password rules, but (a) they're getting used to them and (b) whether they realize it or not they would rather have a more complicated password than have their account compromised. I assume your passwords already contain at least one of everything, right? Uppercase letter, lowercase letter, number, and symbol. If not then they're not as secure as they could be, and I know you hate when stuff isn't as secure as it could be. So there shouldn't be any problem with that. Length is the only other requirement, but it's almost always just minimum length and I can't imagine your passwords being less than 8 characters long - the most common minimum length. Stuff like a maximum length, or "no more than N" types of characters, and certainly not "may not contain any of X" symbols (not counting, like, not containing a name or username) is bad and should not be used. Naturally. I assume we're not talking about those. What makes no sense is why your random passwords would be not secure enough to meet a site's good password requirements, and why altering your rules to fit those requirements would make them weaker. Fun fact: Passwords used by Visa's "Verified By Visa" program have to be, like, Inexperienced users will wonder what they have to do to make the bar go green, get longer, or do whatever, so some mention of guidelines is good. But if someone is registering with an important system - say, their bank - simply encouraging them to use a strong password may not be sufficient. A red meter tells me that my password of "lincoln15" sucks but doesn't actually make me do anything about it. Password constraints exist to make sure people pick technically-secure passwords. They don't always have to be used, opting for the strength meter or a mere list of guidelines instead, but sometimes they should be.

You drive a hard bargain... You have a deal. But you need to do me a favor: I have this friend that needs help moving some money around. I can't be too specific but he's a VIP in Nigeria, so you know he's trustworthy. I've already done what I can, and he even paid me for the time and effort, but he needs to get more people involved because he has so much money that his government would get suspicious if he had just one person help. He gave me 6% of the transaction fees because I'm his friend and he knew I needed the extra cash to pay for an extension to my house (four bedrooms just isn't enough, you know?), but I'm sure I could negotiate 3-4% for you. You'd have to prove to him that you're willing to help by transferring a bit of money to him first - just enough to prove that you have a working account with some real money in it - but as soon as he sees you've done that he could get right on with the complicated transfer work. I say "complicated" because you'd probably see your bank account balances fluctuate for the first couple days, but don't worry because he knows what he's doing.

Build a gooey in Visual Basic to backtrace the IP. I can. Send me the $50 now and I'll get right on it. It'll probably be a while until I'm done so don't bother asking me for things like status updates.

I really don't like them but a stored procedure might be best. A few lines to lock the table, calculate the IDs, insert, and return the ID(s)... then a few more to handle potential errors. The separate table can do it, but either you move the IDs into it and always have to do a JOIN (or use a view), or you copy them and thus store the IDs in multiple places in the database. Huh. I hadn't noticed this was in PHP. Moving... The column that should auto-increment goes last in the primary key. So (accounts_id, id).

Actually it does. Make the primary key be (id2,id1) and put auto_increment on id1. Oh wait, you said InnoDB. And I assume moving that table to MyISAM isn't an option. NEVERMIND. ...Maybe a trigger? Or a separate MyISAM table just to generate those IDs?

Cloning elements will not also clone event handlers. 1. Change your New button (preferably Copy too) to use a class instead of an ID. Remember: IDs must be unique so if you create a clone then you'll be duplicating the ID too and that's not good. 2. When DOM events happen in Javascript they happen to the original element as well as all parent elements. With .on you can apply an event handler to a parent that only fires for specific children that match a selector, whether they exist now or in the future. Use that to tie your New action to all buttons in the entire document that match that CSS class you picked.

You're trying to call fetch_assoc on whatever the setFetchMode function returned. 1. You need to call it on a statement object. 2. You might be confusing PDO with mysqli. PDO does not have a "fetch_assoc". Use one of these instead.

I'd avoid the closures: they come with increased memory usage that does not get cleaned up until you use hundreds or thousands of closures. By design, which I still don't understand but is intentional. If you want non-global functions, use namespaces or utility classes.

+1 to storing. Think of it not about the user answering the general "Linear Algebra" quiz but about them generating their own dedicated "Linear Algebra #1234" quiz and then answering it.

Don't do anything. The only thing you should ever do with a password is make sure it is "secure enough": letters, numbers, symbols, minimum length, not a common password, doesn't contain their username, that stuff. The odds of two users picking the same password and getting the same salt are astronomical and, most importantly, it doesn't matter if it happens. (Would be cool to see, though.) in b4 jacques

Sounds like it requires approval from both the M and AM. So two flags, like in case the M approves before the AM or vice versa. +1 to how it depends what other data is involved. Do the M, AM, DM, and executives all have more or less the same data associated with them but have different ranks? Will some information need to be tracked for some positions and not for others? But on that note, I'm not sure how much needs to be represented here in the first place. This is part of a sort of hiring process, right? Then these tables should track only hiring information - when someone applied/was headhunted, approval dates, notes, etc. - while actual employee data for the people who have been successfully hired belongs elsewhere.

I think Groot is trying to say he wants to make the page on the other site do something, such as open a popup window upon arrival. If that's the case then no, it is not possible. You cannot make someone else's site do something it wasn't designed to do.

D:

Is there a particular reason why it can't simply be a number? Maybe there are other alternatives available - for example, substr(md5($id), 0, 13) (the same length as a uniqid) for $id between 1 and 1000000 is unique, so unless you plan to have more than one million employees that would be an easy option.

Why are you generating the ID by yourself? Don't do that. Use auto_increment.

Ideally, the controller is in charge of shuffling data between the model and view, and has no knowledge of how the data is stored (model) or how it's presented externally (view). So it should gather together the information that the view will need, and the view should take that data and arrange it into whatever HTML format is necessary. The controller is probably a class and the view is probably a file, but neither of those are actual requirements.

You are executing that file twice, as in through two include()s or require()s. At least. Don't do that.

Is that actually what you did? If so then you outputted "data=$doc". Either output the value of $doc at those two locations, or post your real code.

Generally APIs work either (a) server-side with something like cURL or (b) client-side by using an external Javascript library which does the API calls and thus obeys the same-origin rule. If you were supposed to write your own Javascript code to interact directly with the Maps APIs then Google would have to set up CORS to allow that. Proxying is probably the best solution. Any reason you're trying to stop doing that?

It's just a form of URL rewriting. Every time someone requests the directory itself you redirect them somewhere else. Looks like RewriteEngine on RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^ - [F]which will actually send a 403 Forbidden if they request something that is not a file (ie, is a directory or does not exist). IMO that's better than a redirect. If you really want to redirect then just change that RewriteRule accordingly, making sure it sends a permanent redirect (R=301) instead of the default temporary redirect. Oh, and that would go in a .htaccess within the first image folder: if your images go in /images/* then you'd put it in /images/.htaccess.

Where is $xpath coming from? Did you forget to create it?

So what you're saying is that var v = $("select[name='"+vt[i][0]+"']").val();is getting you the wrong value? Remember that vt[0] will be like "type" or "name" which means you're doing $("select[name='type']").val()

No reason why we couldn't do it... But before that we're considering what to do with the forum software itself. Like, should we upgrade, or switch to something else besides IPB? Or upgrade now and switch later?

I'm watching a TV show with a duration of 1 hour. When does it start and end?