At 11/10/09 10:20 AM, mayoarm11 wrote: Hi, I was wondering if someone could help me with a php script.

I need to create a script that creates .txt files with a name that is given in the url link. For instance, the call:

domain.com/subfolder/runScript.php?name=
"text name"

should create a .txt file with the name 'text name' in the subfolder. I don't really know how to get parameters and apply them to the code I've been given. Thanks very much in advance for any help.

<?php
$fp = fopen("newTxtFile.txt" , "x+");
fputs($fp , "Text that will be saved in txt file once made");
fclose($fp);
?>

If you really have to do it this way, make VERY sure your sanitize the file name properly as that kind of approach is a prime target for all kinds of vulnerabilities.

At 11/11/09 04:01 AM, DFox wrote: I still think it's a piss-poor practice...

Who is this reply aimed at?

At 11/10/09 09:30 AM, urbn wrote: Google mail has remember me, and it remembers me for a month without needing to enter a password for that whole month?

I wouldn't know about that, however, when I access Google Analytics, Webmaster Tools, etc. it prompts me for a password.

At 11/11/09 02:47 AM, Nishinku wrote: And just to clarify for you guys, because there seems to be some confusion. I give all users an id in the database, and thats what i save in the cookie, even if you did modify the cookie you wouldnt know how to alter it to fit another user unless you could access the DB. So i dont put up any usernames passwords or whatsoever in cookies.

As long as the ids cannot be enumerated.

Check your php.ini or ask your host to ensure cookies are enabled for your account (check the session.use_cookies directive). Secondly ensure cookies are enabled in your browser.

At 11/10/09 06:54 AM, BillysProgrammer wrote: The only reason why I stated that you can use it for a password is just for easy access for users. Safety is my #1 priority, but when it comes down to ease of use, your going to have to throw it out the window just a bit.

For regular sites it's probably fine, but for anything secure or that involves personal information it should be avoided. You will notice sites like Google has the remember functionality but only remembers your username, it still prompts you for your password once your session has expired.

Ensure you have cookies enabled in your browser. Secondly, paste your full code if possible. Are you getting any PHP errors?

At 11/4/09 12:22 PM, Nishinku wrote: ok so in login.php i start a session for the login containing the user id from the database.

Don't do this. Ever. All it takes is for somebody to modify the cookie and will then be able to be logged in as any other user (granted your user ids are sequential, e.g. an auto-incremented primary key). If you really need to save their state, store a unique, non sequential string such as a session id or anything similar that cannot be enumerated.

At 11/9/09 06:03 AM, BillysProgrammer wrote: The most you should do with cookies that has to do with the login system would to be "remember me" kind of thing. If they choose say, a textbox, then they will have their email (or username) stored, possibly their password, and when they view the page again after they close the browser, the cookie would embed its contents into the input area specified.

A "remember me" function should, at most, store the username only. NEVER store the password in a cookie.

Little disappointed about Orgasm Girl 2. Glad about top 10 though!

Orgasm Girl 2, by Deja-Vu Type: Game Rating: Adults Only

Looking forward to the Flash off winners...

At 10/21/09 10:59 PM, FallingTears wrote: jQuery is pretty neat. What are some things jQuery can do?

Quite a bit, I suggest checking out http://docs.jquery.com/Main_Page and also have a look at the UI reference at http://jqueryui.com/demos/ for some demos.

At 10/15/09 07:57 AM, thisissam wrote: So I'm working on a new idea and I can't be bothered to write my own sessions stuff, so I figure I should just use PHP's built-in sessions. But it's been about 5 years since I've used them and can only remember what session_start does, and that's because it's kind of self explanatory.

Can I really just start them up, store a user ID and time in them and use that to keep users logged in?

If I remember correctly, the data is stored in a file somewhere on the server while all that's in the cookie is a session string generated by PHP, so what I put in there isn't really the issue. I suppose what I'm asking is, how easy is it for someone to hijack a session?

One of the easiest way to hijack a cookie is via XSS, so ensure your application is protected against these kinds of attacks. If you generate a custom session ID and use cookies to store it, be sure to set the "httponly" flag for that cookie to true, that will (in most cases) allow the cookie to be accessed via HTTP only (and not, e.g. JavaScript) and ensures a small amount of protection against session hijacking.

For highly secure systems it's always advisable NOT to offer the option to remember your login details for next time. If you want to help the user out, store the username only at the most and require the password be entered each time they visit or their session times out.

I use jQuery for all my AJAX needs at the moment.

At 10/17/09 08:23 AM, Wonchop wrote: Oh Yotam, you silly billy.

One of the main issues with Orgasm Girl 2 (despite the generally depravity and such), was how it locked off previous levels after you played them. Also, considering it's been about 5 years since the last one, you'd think there'd be some animation in there.

There seems to be the general misconception that I've been working on the game for 5 years which is not the case. If you play the game you will clearly notice it's not a game that has taken 5 years to produce.

Do yourself a favour and test your feed XML using this validator:

http://validator.w3.org/feed/

Once you fix the problems, test it again and see if it made a difference.

Your feed alone worked fine when I access it using Firefox. Do you have a URL on your server I can test? Is the server perhaps giving an error when serving the feed?

There are loads of subliminal messages and imagery all over the meda: adverts, movies, songs, etc. But good find!

A classic one is the spelling of "SEX" down the ice cubes:

Looks to me like the host has it so .html files are parsed as PHP. In addition, seems like the "short_open_tag" directive is set to true which is why you are getting that PHP error with your XML declaration.

Your DOCTYPE is messed up. Change line 1 to:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-
transitional.dtd">

Traditionally Sweet 16 parties celebrated the girl's virginity, but as most girls are no longer virgins by 16, it's primarily held to celebrate their coming of age.

It depends, do you require design and XHTML as well, or the programming part only?

Run the text through at least strip_tags() and htmlentities()

At 5/7/09 12:26 AM, apeskape wrote: Actually the casing on mysql_query doesn't matter. Since you are such a badass with mysql/php why don't you help instead of criticize?

Just because you can do it doesn't mean it's right. The standard is lowercase function names.

At 5/6/09 11:58 AM, BillysProgrammer wrote: See, that makes sense, instead of saying it uses a cookie.

Still uses a cookie :P

The only way you can use sessions that DON'T use a cookie is by appending them to each URL, but this is simply not secure and a pain in the ass for SEO purposes.

At 5/6/09 11:44 AM, BillysProgrammer wrote:

At 5/6/09 11:42 AM, Deja-Vu wrote: Sessions require cookies too.

No they dont. There not cookies..

Yes they do. HTTP is a stateless protocol, so how do you reckon the server remembers your session data? Using a session COOKIE. The session id (specified in the cookie) is unique and is a pointer to the session data on the server, so the cookie doesn't store the data itself, but is a pointer to the session data on the server.

Sessions require cookies too.

On a webpage the best you can do is to link to the document (provided you want to keep it in Excel) that will bring up a dialog asking you whether you want to save the file or (download and) open.

For projectors you can only open executables (.exe, .bat) and they need to be in a fscommand sub-folder. Once way to overcome this is to use a wrapper application like SWF Studio (http://www.northcode.com/) that includes an API allowing you to open any files directly. I've used it on some projects and it works brilliantly.

At 5/5/09 08:17 AM, SecretDreamer wrote:

At 5/5/09 08:11 AM, Deja-Vu wrote:

At 5/5/09 06:55 AM, Wonderful wrote: I swear we had a thread like this a week or so ago. IIRC the answer had to do with the date() function.

You're right: http://www.newgrounds.com/bbs/topic/1052 698

Im so sorry, I forgot I had already asked the question on Newgrounds
My brain has been so fried recently

I apologies

No problems! I take it you have not yet found a solution? Have you tried what I suggested in the previous thread?

At 5/5/09 06:55 AM, Wonderful wrote: I swear we had a thread like this a week or so ago. IIRC the answer had to do with the date() function.

You're right: http://www.newgrounds.com/bbs/topic/1052 698

At 5/5/09 12:58 AM, WoogieNoogie wrote: No. Not at all.

Are you serious? Of course it's possible, I've done it multiple times in the past.

You have 2 ways you can go about doing this:

1) You can use PHP to connect to the inbox and check the messages, use the functions here as a starting point, there are quite a few examples to get you started: http://www.php.net/manual/en/ref.imap.ph p

2) You can pipe all incoming mail for a specific email address to a PHP application. I've done this before for unsubscribing from a newsletter. You can get some instructions here: http://wiki.jumba.com.au/wiki/Pipe_an_em ail_to_a_script

At 4/30/09 07:12 AM, yhar wrote: Hi,
I'm building a log in system, normally I just use sessions but I want to try with cookies now.

I have a theory on how to do it securely:

- Generate a random 20 character key for a user, store it in the database as "cookiename"
- Create a cookie, with the name of that 20 character key and the value as the session ID.
- Create a cookie that stores the username of the user, called "username".
- Upon loading up the page, and there isn't an active logged in session, the script checks if there is a "username" cookie. If the username cookie is there, the database is queried for the usernames cookiename.
- The script then checks if there is a cookie called the 20 character key, if there is it retrieves the session info for that user (the session is stored in that cookie) and applies it, meaning they don't have to log in again, it logs in via cookie.

Is this theory/idea secure? The reason to use a different cookie name for each user is that the session can't be hijacked. They'd have to guess the cookie name, which is a 20 character random key and also the session ID, they would also have to have the same hostname and browser. This means that it's literally impossible to 'hack' it.

Do you think this is a good idea? Secure? Worth the hassle? Or am I going about this the wrong way, have I missed something? :)

It really depends how secure you want the application to be. If it's very important then you should immediately scrap the idea of auto-login based on cookies. "Remember me" functionality should only ever be used to store non-secret items like the username for example. You will notice many sites (Google for example) may allow you to store your login info, but only your username is saved. Each time you start a new session it still requires your password.

To prevent session hijacking you really also need to filter all user input (and output!) as XSS attacks can be used to redirect all the user's cookies to a site that collects the sessions.

Focus on other areas of security as well: secure login (SSL), storing of passwords encrypted (with a salt to avoid rainbow table attacks). To counter brute force attacks, you may want to lock the user amount for a certain amount of time after a number of unsuccessful login attempts.

You could also use the PEAR Benchmark package - http://pear.php.net/package/Benchmark (a little more involved).

At 5/4/09 02:57 PM, BillysProgrammer wrote:
BTW, use google next time.

This forum is here for a reason.

At 5/4/09 03:02 PM, DFox wrote:

At 5/4/09 02:47 PM, elbekko wrote: Actually:
http://www.h-online.com/security/Risky-M IME-sniffing-in-Internet-Explorer--/feat ures/112589

OK, so I guess you want to check the integrity of image files also, although I'm not sure the easiest way to do that. Do you know of any classes for this?

Check this article for one way of doing it: http://www.rorsecurity.info/journal/2009 /2/11/mime-sniffing-in-ie-enables-xss-at tacks.html