New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
As said, clearing cookies would get around this. You'd be better off storing email address against IP address and checking against them when the user request a 'code'. However, you'd use a DB of sorts rather than storing this data in a flat file.
joepie91: You have the same race condition as the text file.
You need to look into Tranactions and Select for update
For what you're doing, yes. If you lock the file and two users try to access it at the same time, the second user might wait a millisecond longer. There's hardly any code in there to worry about. The codes will also be a lot easier to manage in a text file. I wouldn't consider moving to a database unless you were sending out thousands of codes per day.
As @subigo said, there's no point in making anything more complex unless you have to. Follow the KISS principle (Keep it simple, Stupid!).
However, you should store it as logs. This is assuming you want one per person/email address, you would have to log that somewhere.
@dnom thanks for the suggestion. Will look into it if my site gets large amounts of traffic.
@Dom Cookies are certainly not a great use at the moment, however the vast majority of users won't even understand what a cookie is.
@subigo thanks
. I'll be releasing codes on the same day (E.g. Monday) on a weekly or fortnightly basis, starting only with about 10 or 20 codes, meaning it will be very low usage for a while. I wasn't sure if a database would be overkill for this kind of use, so thanks for letting me know that it would be!
@Adam Ahahaa, I like that principle :P. Think I might KISS
.
@debug Yes, this is one of my next tasks. Going to log times accessed, which code was accessed, email address used and IP address. Obviously this won't stop people finding a work around, but at least it will give me something to monitor.
I may however, record IP addresses into a separate text file. Then when the user requests a code, it first checks that their IP does not exist in that text file.
Any other suggestions? I'll probably share my code at some point too, as it will undoubtedly be able to be improved upon, but could potentially be of use to somebody at some point, even if it is extremely simple.
Doesn't SQLite lock the table and make other attempts wait for it to unlock, thereby handling the locking itself?
In general, yes. But there have been several bugs in sqlite2 that have caused race conditions. It's really no different than locking a regular text file in php... but I'm not knocking sqlite. I prefer it to mysql 99% of the time.
I'd say there's more potential for this going wrong when implementing your own locking, than when using SQLite for it, unless you really know what you're doing - and judging from the question asked, I don't think that's the case. Not saying that's a bad thing (everyone starts somewhere), just that because of that, a text file with homebrew locking would not be the best solution.
Out of curiosity, what exactly could "go wrong". As @joepie91 has said, we all start somewhere and personally I've never done any sort of "locking".
Other than a user seeing the text file, what could go wrong?
When two people try to access and write to a single file at the same time it can cause data corruption and/or the wrong data being transmitted. So ideally you should be locking and unlocking files when they are accessed. Think of it like a key. User A wants to access a file, which is unlocked, so they claim the file and lock it for themselves. Until user A unlocks the file, user B will have to sit around and wait for access.
http://php.net/manual/en/function.flock.php
Not too sure on the implications of cookies now days, if it is to be used in a business scenario, under new regulations, don't you actually have to explain to end users what you are using the cookies for and what they will be saving?
That depends on your country.
@gsrdgrdghd : do you know if it depends on the country of the business, the server, or the intended users?
Edit : What about personal sites that use cookies for informational purposes?
I'd say the laws of the country in which the business is registered as well as the laws of the country in which the servers are have to be followed.
@aubs Yes, I am well aware of this. The site isn't currently hosted on a domain, therefore I do not see it is being hosted "publicly" as it is only accessible through my servers IP address. The server that it is sat on is located in the USA, but I live in England, and I know that the rules regarding cookies over here are that it must be publicly viewable to the users that cookies are being used, along with an explanation of why.
I shall be placing a disclaimer on my home page stating this before the site goes live (on a domain is what I class as "live").
Even if it doesn't have to be this way in any other country, I would personally still do this as in my opinion it is better to abide to as many countries rulings within one product, both to keep yourself secure and to provide familiarity to customers, whilst also being prepared for any future laws which may have to be stuck to.
Thanks for mentioning it though, as I'm sure not all people will be aware of this.
For the locking issue, use only 1 PHP process.
@dmmcintyre3 Sorry, I am very new to PHP.. by process, I assume you mean one script?
Currently (and for the foreseeable future) I have:
A text file containing codes
A CSS file for styling
Index page (uses PHP to start a session)
Separate PHP file to handle all of the communication with the text file
So 2 PHP files, a text file and a CSS file (plus a favicon)...
Would this still be open to locking issues?
You're storing your codes in plaintex. Change it now. MySQL control with PHP is extremely easy.
That's probably the cause of your locking issue, too.
He doesn't have a locking issue and you give horrible advice. Carry on.
Yes, because MySQL totally doesn't store data in what is essentially plaintext.
It's called 'overkill'.
What locking issue?
For the record, these codes are to be used with another company. Each code can only be used once, and has no monetary value. It's simply me making the codes more accessible.
Whether or not the codes are in plaintext is completely irrelevant seeing as they're hardly million dollar off codes.
Even if somebody got access to the whole file, it doesn't affect me at all.. will only irritate others who are finding it difficult to get a code.