Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


gizmola last won the day on November 6

gizmola had the most liked content!

Community Reputation

147 Excellent

About gizmola

  • Rank
    Prolific Member

Contact Methods

  • AIM
  • Website URL

Profile Information

  • Gender
  • Location
    Los Angeles, CA USA

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. MySQL doesn't have a concept of a "site". It has connections, users and databases. All MySQL can do is accept queries and process them. A PHP application looks the same as a NodeJS application, looks the same as a dba sitting in the mysql command line client issuing sql statements on the fly. MySQL gets the SQL statements and processes them. To add to benanamen's explanation, there will be a mysql server running somewhere. Often I have seen a dedicated server or set of servers configured, so the mysql server is often not on the same server as the web accounts. An associated mysql user account gets created, and permissions are set up so that any databases created are owned by that user. You of course are disclosed the username, connect string and password for your account which you configure in whatever applications you have that utilize the MySQL client libraries to connect. After that, any connections your application make work exactly the same as if you had your own server or cluster of servers. What the hosting company can do is control things like the # of connections you are allowed to make, so as to limit your application on that basis, but as far as the individual connections are concerned, they are all equal from the point of view of the mysql server, and as described -- it's a "First In" queue. I hesitate to say FIFO queue, because queries are not equal, and mysql will return the results as soon as it has them, so a long running query could come in first, and other shorter queries could come in after and be serviced with a result before the long running query. If you have a specific question or concern, it might help to elaborate on that.
  2. gizmola

    $_SERVER Array Variables

    I can't imagine a scenario where the gobbledy-gook of a system you apparently are trying to create would be justified, or possible within your demonstrated engineering capabilities. You are talking about trying to create a system that requires a user to only use one workstation and browser to access your system. I don't know what your system would be doing, but it better be providing literally life saving services, because short of that, nobody is going to put up with the restrictions you have in mind. They are anti-user, and when you make things difficult for users, they stop using your system, or never even stay long enough to pass the entry point. It is damn difficult to get anyone to sign up to use legitimately valuable services, which is why you see so many systems that integrate with facebook, google and twitter, so that you can create your account and trust authentication from those systems to allow access. Furthermore some of your plans reflect an apparent lack of understanding of Internet basics like NAT. In your system, if we were to follow along with your plans, for a large company with perhaps 1000 employees at a particular site, you plan to only allow 1 employee there to use your system. Ditto universities, or even an average household: "Hey there roommate, I just made an account at this site, you should too!" "WTF, the system says I'm banned!" Since you are focused on investigating a client IP, I will say this about IP addresses -- they are reliable at least to the degree that they reflect the tcp socket connection from the client to the server. That information bubbles up to PHP from the IP layer, to the server, and finally to PHP's $_SERVER superglob. The problem is, that a client could have bounced through a variety of gateways, proxy servers or VPN prior to the point that you are finally connected. In many sophisticated hosting environments there are things like load balancers or reverse proxy servers that sit between the client connection and the server which interfere with $_SERVER['REMOTE_ADDR']. Rather than see the client IP, you instead see the IP of the proxy server. If you have that sort of environment, then you can examine $_SERVER['X-Forwarded-For'] or $_SERVER['HTTP_X_FORWARDED_FOR'] variables. These may be arrays with a series of addresses. Again you have the issue that these are provided by the "client" so if it is a proxy server you can depend on at least the most recent address to have been the one that made the TCP socket connection to YOUR proxy server. Other legitimate proxy servers will provide the same data. However, someone who is taking steps to hide their origin is not going to be prevented from obscuring their IP and there is absolutely nothing you can do about it. Almost everyone uses NAT in some form, so the actual person IP address of a workstation on a network is never going to be visible (and would also be useless if it was, since these will be non-routable IP addresses that are shared by hundreds of millions of users). Solutions to the issue of certification and authentication, when people have real and legitimate reasons to solve them, involve cryptography. What you are trying to do can be accomplished using X.509 certificates which have support built into browsers. In a nutshell, at account creation time you would generate an client certificate for that user, installing that into your server, and then providing the signed cert back to them in a specific header (application/x-x509-user-cert ). This will cause the browser to prompt the user to install the cert into their browser. If they accept you know have a reliable way of identifying a specific user. At that point, whenever they connect (must be under SSL) you'll be able to authenticate them back to your system via that particular certificate. Those without a client certificate will be unable to connect. You can think of this as white listing. It is highly effective but is typically used only in environments where the system knows in advance who their allowed users are. Trying to use it in a public facing website with an unknown user base is something you just don't see because the benefits of trying to do this far outweigh the tolerance that people have for a system that has that degree of odious overhead and invasion of their privacy. In conclusion: The types of things you are obsessed with are all edge case items. No quality system begins with the premise that the #1 goal is to try and catch and outsmart an imaginary horde of people attacking your site for reasons unknown. This started as a specific thread about the contents of $_SERVER variables and then escalated into fairly delusional territory, with a dash of your personal Devshed drama thrown in. And let's just be clear about one thing: If you ever bring up your personal issues regarding your Devshed access again, which are irrelevant to this community, then your access to this community will end as well. It's off topic, it's a waste of people's time and efforts here, and it's rude. I just want to be clear that I won't tolerate it again.
  3. gizmola

    Start Session only if parameter exists

    I have tried in my career to gain an understanding of things at the most granular level possible, which at time involves breaking down the components of a larger system or making an effort to demystify a process that might initially seem to be complicated and confusing. I was reminded of this when you described a session as "running." A session doesn't run and isn't really what you seem to think it is, but to understand this better, you also need to be clear on how HTTP protocol works, and how web servers and web browsers interact. If you aren't clear on for example, what HTTP headers are, what cookies are and where and how cookie data is provided, and how PHP scripts work, then you might need to do some investigation into those fundamentals to fully understand my points, but I'll take a stab at the topic regardless, in hopes it might shed some light. By default sessions are really the manifestation of 2 simple concepts: PHP can examine a client request and look for a session id. This could be a url parameter, but by far the preferred method, is to read it from cookie data. I will just state that for the record, the way cookies work is that when a browser makes a request, it looks at the domain it's requesting, and IF it has cookie data stored for that domain, it sends all that cookie data in every request (in the HTTP header of its request). For this reason, once the server provides a session id, the client will pass this Id back to the server in every request, until such a time as the cookie expires. Essentially the session Id can be thought of as a locker key that opens a locker and can be used to add, view or remove items from the locker. PHP has the ability to take a set of variables in memory and "serialize" them. Take a look at the php serialize() function to understand how this works. By default, a PHP session is nothing more or less than the $_SESSION array run through serialize and stored in a text file on the server. What PHP does for you, is associate that serialized file with the session Id that is transparent to you. The session files also have expirations and garbage collection rules that get triggered when a PHP script runs which may or may not remove expired session files. The lifetime of a PHP script is typically very short. When a request resolves to a PHP script, the server runs the PHP script, doing whatever initialization it needs, including reading HTTP request headers and associated data into the various "superglobal" variables like $_SERVER, $_COOKIE, $_GET, $_POST etc. IF the script starts with session_start(), then PHP looks for the session Id (which it gets from a cookie) and if found, tries to find an associated session file. Should that session file exist, PHP reads the file from the file system, runs unserialize() on it, and stores the contents in the $_SESSION variable. The only "magic" involved in PHP session functionality is this: While your PHP script is running (and the session system was instantiated via session_start()) if you store something to the $_SESSION superglobal variable, PHP will overwrite the session file with the serialized contents, so in a way you could think of the saved session file as being the most current snapshot of the $_SESSION array. When the script completes, there is nothing running --- just a file that is sitting on the filesystem of the web server. A session id can be anything you want it to be, but by default it is an md5() hash of a few different things that concatenated together should be unique. This provides enough obfuscation so that someone trying to attack the system has no real chance to guess another user's session Id. When a request is made to a script that begins with session_start(), if a session does not exist, then PHP will generate a session id, initialize a session file for future storage, and it will then provide the session id in a set-cookie header. So when you understand how this all works, you might realize that there is a way to build your "session optional" mechanism, keeping in mind of course that sessions aren't some magical persistent process running on the server. What you could do is rather than depending on a session to store your affiliate id, store the affiliate Id as a cookie. You would then session_start() only when the 'affiliate_id' cookie exists. This is not that different from how PHP itself, only attempts to find and unserialize the session data, when the browser request includes the session Id cookie. As others have pointed out, it's a lot of effort for very little gain, as the overhead is typically minimal, however it is not uncommon to see large sites implement some variation on this idea, to avoid creating sessions in cases when they are not wanted.
  4. gizmola

    $_SERVER Array Variables

    You can save yourself a lot of time using print_r or var_dump in the future for experimentation and debugging: var_dump($_SERVER); To reiterate what Requinix just explained, these variables have various sources and reliability. They are dependent on the environment and configuration and don't always exist. Another very helpful technique for learning more about your environment is to utilize phpinfo(). <?php phpinfo(); For command line php run this from your shell: php -i Spend some time going through the output of these commands, and use that to read the manual for clarification and additional information. As for browser/client detection, I'm not sure what you want to know about those scripts you cribbed from comments. Neither one is even attempting to do more than a mediocre job. There are component libraries out there like https://github.com/sinergi/php-browser-detector or https://github.com/Wolfcast/BrowserDetection you could use. But again as Requinix warned, variables like these are provided by the client and can be spoofed.
  5. gizmola

    SQL injection Hysteria? Or not?

    In a nutshell -- in the olden days you needed to be concerned about "escaping" your SQL strings. Why? Because anything that interfered with the parsing of the SQL statement, which I'm sure you know is as simple as a string that contains quotes in it, would break the SQL statement. So as simple as: $username = "admin"; $password = "' OR 1=1 OR 'password' = '"; $sql = "SELECT * FROM user WHERE username = '$username' AND password = '$password'"; This issue was addressed by functions like addslashes, mysql_escape_string and mysql_real_escape_string. What this indicated clearly was that dealing with input and the potential of quotes and in some databases, characters that allowed one to batch multiple SQL statements together in one statement, was a potentially complicated and highly dangerous mechanic. For this reason alone, using prepared statements are beneficial, because you no longer have to use any string escaping functions. The other benefit is that these SQL injection attacks are no longer possible when you use prepared statements.
  6. gizmola

    Encryption? Salt? Secret Key? Whaaat?

    A salt has 2 purposes. In both cases, they assume that an attacker got access to your data, but not your code. As already explained, this happens all too often due to SQL injections and coding errors. If your server is fully compromised it doesn't really matter what you did to encrypt your data, which seems to be a concept you are stuck on. When used with a hash, a salt is added so that a Rainbow table would not be effective. Keep in mind that you can not decrypt a hash. All you can do is provide input, hash the input, and see what hash is produced. For passwords, you compare the computed hash to the stored hash, and grant access when they match for a specific user name. So one way to try and reverse engineer a hash, is to create a database of inputs and hash values. This can be very effective because so many people use poor passwords (names, common words, simple phrases). A salt adds some noise to the raw input that changes it sufficiently to defeat a rainbow table. A best practice is to provide a different salt for each hash, which then makes Rainbow generation, even with salts, a very tiresome activity. If they know a global salt, they can generate a Rainbow table with that salt. If however, you have a salt for each row/hash, they have to create Rainbow tables for any/all rows, and that is going to be time consuming. Some values are not appropriate for hashing because the application requires the ability to access the original value. Your AES_ENCRYPT example is one such scenario. You typically see this used with privacy values like social security numbers, pins that you have to disclose to a customer service rep, or credit card numbers. In the case of AES_ENCRYPT, that is not a "salt" per se, but rather, a passphrase or key. You can hash a value without using a salt, but you can't encrypt a value without a key. That is how they differ. I will say that when people use the mysql AES_DECRYPT() function call, it is often with a single key/salt value purely for pragmatic reasons, as an individual key used on a per row basis would mean that you could never do a query against the entire column ie. SELECT * FROM TABLE WHERE AES_DECRYPT(SSN, $key). Hope this helps you understand these concepts a bit better.
  7. gizmola

    Instagram API Intergartion

    A brief look at the instagram API tells me this is not possible.
  8. GoDaddy hosting is not known for its quality. With that said, I would check out this thread on solving issues with configuration and phpmailer.
  9. gizmola

    Pdf to html Converter needed

    This is an intrinsic problem with dompdf: you are at the mercy of the styling/fonts and css. You need to insure that your html page fits your desired output, but there are other libraries out there that might be a better fit for this use case: namely tcpdf or mpdf, or even the father of php pdf libraries (fpdf).
  10. gizmola

    HELP with php sript

    The reality of this issue is that it is most likely non-trivial. We have to assume given the information you provided that the code is the same. If there is data that is also the same. Beyond that, there is an incredible number of things that could be different between the 2 environments. Basically what you need is someone experienced in these matters to go through the environments looking for the source of the slowdown. While I understand the reason for Requinix's advice, this is most likely a configuration/environment problem that requires detailed understanding of system administration AND php AND your application. To begin with, it would be good if you utilized chrome development tools in the Network tab, and load the page in question, then provide that so we can see what is being loaded on the page, and where the delay comes between the 2 servers.
  11. gizmola

    Need help getting last insert id from mysql

    The PDO api is easier to use and more natural than mysqli. There are some really annoying things in mysqli that you quickly come to with things like prepared statements. Prepared statements are essentially mandatory for handling all query parameters and data, if you want to write quality code that does not have intrinsic SQL injection flaws or risks. You can read this article for a discussion on issues with mysqli prepared statements if you want to see one of the major annoyances with it. As for PDO, the same guy wrote a great tutorial on PDO with mysql that we point people to all the time. Read through it, and you will become a highly proficient PDO developer very quickly. If you really want a database class to use that wraps PDO, then you can use the Doctrine2 ORM which relies upon PDO/MySQL. You don't have to go the full ORM route with it, but just use the DBAL (Database Abstraction Layer) portion which is a simple and effective database class that offers value for many people. I would highly recommend using that rather than trying to create your own database wrapper class or function library.
  12. gizmola

    Need help getting last insert id from mysql

    Benanamen provided you with sound advice that I agree with 100%. With that said, the answer to your specific question is that after your insert query, you would need to call mysqli_insert_id. Using your example: $sql = "INSERT INTO table (blah blah) VALUES (blah blah)"; $result = query($sql); $id = mysqli_insert_id($dbCon); It does not matter that you have a wrapper function around the msqli_query, as the inserted id is bound to the mysql connection.
  13. Given how you are doing this, a big win would be to ditch MySQL and use a no SQL database like MongoDB which is schemaless and works with a binary json format internally.
  14. gizmola

    need help $url from $value

    I would use Barand's suggestion. With that said, your code has a syntax error and that is why it didn't work as you expected: echo '<p>' . '<a href=' . $url;'></a>' . '</p>'; You have an extraneous ';' in there. To fix it would just require: echo '<p>' . '<a href=' . $url . '></a>' . '</p>'; You are doing needless concatenation of string constants which is one reason I would prefer Barand's take. However, my opinion is that html attributes should be enclosed within double quotes (even though single quotes are acceptable), so a more complete fix would be: echo '<p><a href="' . $url . '"></a></p>';
  15. gizmola

    php code problem from command line?

    Yes exactly. APC cache has no benefit for CLI because the cache is tied to each php process. For CLI scripts the php process gets created and destroyed on each excecution. If you want an in memory cache you need to use one of the old standby methods: memcached or Redis. Those also have the advantage of being independent of the application server, so they are inherently capable of working in a cluster. The other option is to use the shared memory functions

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.