T-G

Personally I don't mind it as long as it's in context. You know what I really hate? Mailchimp's stupid little cartoon monkey spouting off worn interweb memes all over the place. It's mailing list management for goodness sake, it's not YouTube. I find bland, meaningless marketing blurb far more offensive. "The KJN-6 Snakefire will change your driving experience, elevate your soul and energise your synergy" type nonsense. Just give me the info I need. If you want to tag a joke on then fine, but please, for the love of Berners-Lee, just give me the information I need and then have your fun.

You can't just "add security", it's a very long-winded and complex field which will take you (very literally) years to learn to the stage where you can describe yourself as a security professional. I've been doing the computer thing for years and would still only class myself as somebody with a working knowledge of security in my field (mostly LAMP). Assuming that you're doing mostly web based stuff, there two places to start with: Server - learn as much as you can about the server setup you're using. In my case that's file permissions, .htaccess, user management and permissions, SQL security (SQL injection is a very important topic and a very common attack vector), PHP security techniques, hashing and encryption, and (because we handle people's email addresses) the UK Data Protection Act. Users - I manage websites where the client has access to various things, email logins, admin sections of websites, mailing lists etc. The toughest bit of the job, even if your code is 100% perfect, is educating your users in the use of strong passwords and password protection, and avoiding social engineering, probably the most effective attack vector ever used.

Indeed. Facebook are in for some difficult times. They've got an operating loss of something like 60% at the moment, the share price is down to less than half of the initial offering and it's probably going to drop further as more and more shareholders are able to sell their stakes (the next big one is in November). At some point in the next six months I think they'll have some serious issues paying the bills. What they need to do is both monetize on a massive scale and boost confidence in their value, without losing users in the process. The levels of fake users/likes is well documented, but the advertisers seem to be relatively lasaiz faire about it, with a few high-profile exceptions. Whether the advertisers continue to see Facebook as a valuable channel is the big question - in the long term trimming the user base back to "real" people will do them nothing but good, they're in a very strong position when it comes to targeting particular demographics with advertising, but in the short term a drop in user numbers will hit their already weak share price. As a publicly traded company short-term profit will often trump long-term profitability, this is achilles heel which will make or break them over the next couple of years. The other thing they need to sort out is the mess that is their API. It's massively over-complicated, constantly shifting and seems to present a real deterrent to independent developers, who could be the real driving force behind innovation.

I could be wrong about the session_start() at the beginning of includes, it's a pitfall I found ages ago with an old version of PHP, things may have changed. It will throw an error if you include it from a PHP script without session_start() or from inline php in an html file, so I'm simply in the habit of using it in any script which uses session variables. If you're getting a session/header error it's probably because headers are being sent before session_start() is called.

If it's any consolation most sites have attacks on an hourly basis, there's a certain amount of automated attack going on 24 hours a day on most IP addresses across the internet. If it's actually slowing your server down then yes, it's an issue you need to look at. If it's just a few an hour on average then take a look at the logs to see what they're doing, check through your code to make sure there aren't any holes they're targetting, and then make a cup of tea and get on with your life

That's why I said you'd need to get lawyers involved. The ISP who owns the IP will have records of who the IP was assigned to at that time. Whether they'd give that info up is an entirely different matter, but it can be done, that's how Anonymous script kiddies generally get caught.

You need to have session_start() in every file which uses a session variable, having one in the header and including other files without session_start() won't work. In addition, session_start() needs to be there BEFORE any headers are sent by each individual file, having it as the very first thing is usually safest.

Woop! Most welcome. Other people's problems are always easier to fix than your own, once you've spent more than 20 minutes staring at something you go blind to the lurking problem.

Does it still do it with another browser? What's the address in the bar on the blank page? Sounds very iffy to me, could be some form of MIM attack.

You know the situation, you've been trying to get something to work for two hours, nothing works, it's all screwed up, and then suddenly you realise that naming an sql field "limit" was asking for trouble. Click refresh and boom! It all works. What do you do in this situation? Obviously running around with your pants on your head and high-fiveing the cat is the default setting, but lately I've been using Alan Cumming's "I AM INWINCIBLE!" from Goldeneye. It's getting a bit old now and I feel like a change (it's a bit like desktop wallpaper for me). What do you use?

for ($i=1; $i == 1; $i++) { This will cause you problems - you're setting $i to 1, then you're asking it to exit if $i is equal to 1. Try: $i = 1; //set the number for the first div foreach($row as $cell){ echo "<div id='part$i'>\n<p>$cell</p>\n</div>\n"; $i++; }

PHP? To make it easy for my clients to update sections I have the tabs framework as one file, then call <?php include 'tabs.htm';?> whenever I want to include it. Not sure how to get it to jump to the correct tab, but I'm sure there's a jQuery method to do that via GET.

You might find that you have Perl even if you don't have PHP, Perl would do the job.

DDOS stands for Distributed Denial Of Service, the clue is in the "distributed" - there's no (obvious) single machine behind it all. Most of the machines might well be a botnet where the owners don't even know it's happening. You can trace the IPs back to the owners, but you'll probably have to go through ISPs and use lawyers (eg, if my computer was doing it the trace would show a BT server, you'd then have to get BT to tell you who was using that IP at the time.) You can do it, but unless you're a large organisation, a big company or a government, it's probably not worth the hassle. Are all the attacks coming from the same block of IPs?

I'd honestly go with a login if I were you, by far the simplest and most robust system. Two ways to do it, either with files or a database. With the file version you use a file to store the data, eg: (name,hashed-password, config options) dave,482c811da5d5b4bc6d497ffa98491e38,bg-color=#ff0000,font-size=1em pete,db6ae64dfa9e78039db6df5b8edbc38c,bg-color=#000000,font-size=2em etc..... Then you use whichever language (I'd use PHP) to ask for login details, then load the file, then go through each line looking for a name that matches the login name. When you've got that, perform a hash on the password they gave you (I'm using MD5 with no salt for this example, it's not a secure method), and compare that to the hash you have stored (eg if the user 'dave' gives "password123" then the hash you make will match the hash in the file, so you know it's right but you don't need to store the password itself, which is good for security. Once you've got that far you can simply extract the config options from that line of the file. With a DB approach it's much the same, but you're loading a row from a database instead of loading it from a plain text file. If all of this is still too confusing then you probably need to drop back a step and learn a little more about your chosen language. (Cross-posted to your thread, others may find it useful too)