roopurt18

It sounds like the web server you're connecting to is returning a URL redirect. You'll need to check the return code of the request (which I'm not sure how to do with cURL) and if it's one of the redirect codes (300, 301, others?) you'll need to hit whichever URL it is telling you it moved to. Do this until you get a response code of 200 or something in the 4- or 5-hundreds.

It echo's the class name of the instantiated object. This way you can be sure your factory is returning instances of the correct class.

All of my programs are built around MVC for the most part. So essentially there is one file per abstract database object.

I couldn't even begin to guess as to how efficient PHP runs inside of Adobe Air.

Ooooh boy. You're in for some hurt with that script. Instead of checking $param_loggedinuserid != "" every time, why not just have this at the top of your page: if( $param_loggedinuserid != "" ) { return; // or exit(); } You're not using mysql_real_escape_string() anywhere. You're using die() and sending mysql errors directly to the browser. Someone is going to attack your site eventually if you keep that stuff up.

If your server has an optimizer installed then it really doesn't matter how many or how few files are accessed or used by your PHP application. However it sounds like your programs all execute within a global namespace without much use of functions or objects. That style of programming tends to lead to buggy programs.

There's a rule in software development that is often difficult to follow: Never add or program more than you have to. If you don't need the ability for people to purchase extra slots right now, then do not add it. But do spend some time to think about how this software is likely to be used and what extra features may be requested later. Then think about how they may fit into your current design.

You only need to perform stripslashes() on the server if magic quotes are turned on. Not all hosts have magic quotes on and magic quotes is being removed from PHP so you should use the gpc_magic_quotes() function to determine if you need to strip slashes. Also, rather building your post string manually in JS, I'd highly recommend using something like Dojo as a JavaScript framework. You have the following methods in Dojo that would greatly help you in your task: dojo.xhrPost() dojo.toJson()

I'll reiterate that hashing is not the same as encryption. Both are used to protect data. The difference is that with encryption you can recover the original value and with hashing you can not. Once a value is hashed you will never, ever, not in a million years know what the original value was.

I might want to think about the situation where a member might be a bronze member with X uploads. However, they really want Y uploads, where Y > X but they don't need the other benefits of the silver plan. So think now how you might offer this option for a member: You can be a member of plan P which comes with X uploads, but you can also purchase extra uploads without upgrading your plan costing M per extra upload slot. To that end, I'd probably have a column in the DB, probably on the user's record, called uploads_remaining. This column would be integer relating to the uploads allowed by the user's plan and any additional uploads they may have purchased.

I'd make a plan table: id | name 1, Bronze 2, Silver 3, Gold Then in your members / users table you can just add the following columns: id | member_name | ... | plan_id | sub_length_in_months | sub_renewal_date Or something like that.

A = ( 100D + 10E + F ) / ( 10B + C ) A = ( 100D + 10B + G ) / ( 10E + C ) ( 100D + 10E + F ) / ( 10B + C ) = ( 100D + 10B + G ) / ( 10E + C ) Once I made it that far I jumped to: E = B, F = G. But thinking about it now I guess that's not necessarily true.

Are you using any sort of JavaScript framework for your AJAX? Show us how you're making your AJAX post, what value you're sending, and how it's not being received correctly.

What do you mean encoding scheme? Do you mean for a way to serialize PHP objects back to JS and / or vice-versa? Or do you literally mean character encoding like UTF8?

I mean that when your class fails it is printing error messages that include markup; therefore your class is under the assumption that PHP has been invoked under a web server. But what if you decide to use your class for a console application? It's going to print a bunch of error messages that are difficult to read. Also, if your class is being used in a web server application, then you don't want it to print things to the browser. Your class needs to notify to the application, "Hey, something didn't work!" and then the application will decide what to do with it, either logging it, printing error messages, sending e-mails, or whatever else. The job of your DB class is to connect to the database, run queries, etc. but not to print things to the screen.

There is no solution. Solve the first equation for A: A = (DEF) / (BC) Solve the second equation for A: A = (DBG) / (EC) Set the two equal to each other: (DEF) / (BC) = (DBG) / (EC) In order for this to be true, the following must hold: E = B F = G The problem forbids this from being the case. Therefore no solution exists.

Your class is under the assumption it is being used inside a web browser. Such will not always be the case. Therefore your class should resort to more generic methods of reporting errors, such as trigger_error(), logging, or a pub/sub system. Then whichever container (or application) uses your class can determine the appropriate method of handling or reporting errors.

Nested calls to hash_func() defeat the purpose of a salt. The entire purpose of a salt is to negate any existing dictionary database an attacker might possess. Using hash_func( hash_func( $val . $salt ) ) will limit the size of the dictionary needed by an attacker. Now your example uses hash_func( hash_func() . hash_func() ) which still limits the size of the necessary dictionary to brute force against your database. I don't know how many attackers create dictionaries of concatenated hashes for source values so there's no way to really determine how secure your method is. The one thing an attacker can not predict (and therefore can not create a dictionary to attack) is $salt in $hashed = hash_func( $value . $salt ). That, from my understanding, is the most secure method of hashing. There's no need to get extra fancy and nest calls, just create an appropriate salt. Keep in mind though that if an attacker walks off with your source, or otherwise obtains your salt and how you apply it, they can build a dictionary to attack your database.

I'm confused. How are you using the output of time() as a salt? It always changes so you wouldn't be able to confirm a user later. And my understanding is that using the output of one hash function as the input to another, such as md5( md5( ... ) ), is bad practice. The reasoning is because the inner md5() (or whatever hash you choose) has limited output, thus you are limiting the potential characters to be used in the final hash which makes dictionary attacks easier. Do not confuse encryption with hashing. The topic mentions encryption yet the OP is mentioning hashing functions. If you want to perform hashing, then sha1( $value . $salt ) or sha256( $value . $salt ) is probably sufficient. I wouldn't bother with encryption unless you're also encoding your PHP source code with ZendGuard, NuCoder, or another product.

It's been a long while since I used IRC frequently, but efnet and freenode (?) seemed to be somewhat popular. Mind you channels won't be active 24/7. Actually most of the time they're inactive. But you will get tidbits from advanced users in there.

I was tempted to say the same but held my tongue because a local php.ini could potentially cause a working script to break. Just think about the prepend_script (or whatever it's called) setting.

You might as well try and stop the Earth from spinning. Even MMORPGs that require credit cards get people with multiple accounts.

Do you have white space before the opening PHP tag? You have a lot of pointless comments in your markup. What's the point of a comment saying here's a favicon link or here are my JavaScript links? That stuff is self-documenting. That's not what comments are for. And are you seriously storing user passwords unprotected in the cookie's on their machine? And then not sanitizing this input before feeding it to the database?

This is where I'd disagree. The performance hit is negligible.

Single-quoted strings are faster than double-quoted strings. The difference in speed is negligible.