ManiacDan

You should be careful using copyrighted images, even on "demo" websites like this. The pip-boy icon from Fallout is fiercely protected. Also, the top nav doesn't do anything (and hiding the navigation is usually a bad idea) and the grammar is generally bad. The HTML/CSS itself is pretty good though. HOWEVER, there's no reason for the entire site to be frames. -Dan

I think you're thinking about this backward. Inbound links will be in the format of www.yoursite.com/12345-The-Article-Title-Here Your rewrite rule will ignore the title entirely and just use the ID (12345 in this case). Your rewrite rules cannot access the database. You would print out links to your site in the "pretty" format and then the rule takes the pretty format, strips out everything but the ID, and uses it. -Dan

The session works off a cookie called PHPSESSID. That is the cookie controlled by session_set_cookie_params()

The session cookie will be reset for X seconds with every page click, where X is the argument you provide to that function. If someone clicks before X seconds have elapsed, then the timer is reset. If nothing happens (not even ajax calls) for X seconds, the cookie SHOULD disappear from your browser and the session will expire. If you have anything else that restores the session (like your userID cookies) that invalidates this whole discussion.

Are you actively browsing the site? Cookies are reset upon every page execution.

How long have those INET functions been around? I did an IP-based database in 2008 and they weren't available then (or at least my entire team didn't find them). If the INET functions weren't available I'd say storing addresses as strings was a good idea UNLESS you need to do math on them (like subnetting).

session_set_cookie_params(7200); session_start(); Just like that. That will expire the session after 2 hours of inactivity. That comes right from the manual page.

That link I posted goes to the session_set_cookie_params() function manual page. If you don't use that function in your code, then no...not like that.

I won't do your work for you, no. The whole thing I described is maybe 8 lines of code.

Wherever you record the IP, do the check right before that. If their IP matches, redirect them or die.

$query = "select * from videos where title like \"%{$trimmed}%\" or author like \"%{$trimmed}%\" order by id DESC"; // EDIT HERE and specify your table and field names for the SQL query

Guys, OP wants to break the encryption on the FILE THAT URL POINTS TO. NOT THE URL ITSELF. OP: This file was encrypted on purpose. Probably because it costs money. Ask the original author for the unencrypted source code. Doing this yourself will take a very long time, there is no automated "make this readable" code, any work like this would have to be done by hand. Note that it's also illegal in many countries, including the US.

To summarize the points in this thread and add some of my own... 1) The script they used to compromise your site was probably hand-rolled. I wrote web spiders for years, they're very easy. 2) Move your files or secure them with HTACESS so nobody, not even paying customers, can use download links to get to them. 3) Once you've moved them or secured them, rewrite your "download song" landing page so that it accepts a songID, checks whether that song has been purchased by the logged-in user, and then streams the proper song out to the user without directing them to the file itself. 4) Google has nothing to do with this. Other Mp3 sites have nothing to do with this. your site was insecure and followed a predictable pattern, so many people (including probably dozens of your customers) figured out how to get to your files without paying for them.

I find it odd that your thread title includes the answer to your problem. You said you were getting that error on an isset...but isset was the solution to your error. Anyway, don't include files based on user input. Use a switch statement with hard-coded include values to make sure the user hasn't figured out some way of including custom code on your site. -Dan

You don't use the cookie functions to unset the session, you use the cookie function to set a timeout on the session cookie when the users first visit the site. Wherever you call session_start, set a timeout on the session cookie so if the user leaves their browser idle for more than X minutes, the cookie disappears. -Dan

Don't use setcookie, used the built-in cookie management functions

Is there anything that connects these three tables? If the tables have absolutely nothing in common (no unifying structure, no similar columns, nothing in common) then three queries would probably be best.

"Hi, my name is tinytime. I'm having a problem with my code, please tell me what I've done wrong without making any negative comments." Screw that. Go buy a book. You're working off a piece of code from SEVEN YEARS AGO. The functions you're using are OFFICIALLY DEPRECATED. If you think you can change our behavior as a new user then shame on you, because if you were doing your job as a random jerk who's asking us to do things for him for free then your question would have contained: - The steps you had already tried to debug this on your own - Complete sentences - Small snippets of code instead of entire pages - Proper code formatting We are no magic. We can't look at your 100 lines of poorly written code which uses poor practices and functions that are known to be bad and tell you exactly which lines are wrong. I'll tell you which lines are wrong: ALL OF THEM. Rewrite the whole thing and do it right. You're an ass, get out of here. Thread closed.

Things are so much easier when you learn to help yourself. I searched for "escape PHP" on google and this was just begging to be read. Of course, you're absolutely doing this 100% wrong. Don't ever echo entire control structures. What you have here will echo the literal PHP code, not actually do any of it.

You need to die() after header calls session_register has been deprecated for years, don't use it. The manual page for sessions will help with your syntax. -Dan

No. That's the first step. That's what makes some people make the jump from "include files" to "a math library," but a math library is not OOP. Changing pi() to math::pi() doesn't give you any benefit other than namespacing. Being able to say $user->save() and have it dynamically decide which database to save in and recursively save its child objects is a better example.

I will. I just made my first OOP class and I would really like to learn more about it, because I feel that it is the next step for me as a coder. Just because your using classes does not mean your coding in OOP. It's a first step, but it's not the entire picture. Hmm Interesting. Care to explain? Well, mon frere, I wouldn't say this post was in French, n'est pas?

Did anyone say symlinks?

You showed it printing once. You said you wanted it once. Now you're saying "2 times." Clearly you're doing something that prints this more than once. The code you showed is only capable of printing this value once. -Dan

As much as it pains me to say it: read the manual. Functions are one of the most basic concepts of computer science. You have to call a function in order for it to do anything and (in your case) store the return value somewhere. Ask your professor if you need help with this, functions are very simple to understand.