requinix

You have to put the values in the URL. Like in the query string. A naive example would be http://www.example.com/redir.php?email=alice@example.com&campaign=123&url=http%3A%2F%2Fwww.google.com <a href="http://www.example.com/redir.php?email=alice@example.com&campaign=123&url=http%3A%2F%2Fwww.google.com">Google.com</a>But that's blatantly obvious what it's for. I would go for something a bit more sophisticated: a table with the email campaign, email address, and a unique code. Like id | campaign | email | code | count ---+----------+-------------------+----------+------ 1 | 123 | alice@example.com | vlw3igno | 0 2 | 123 | bob@example.com | 3sdfbghu | 0 http://www.example.com/redir.php?id=1&track=vlw3igno&url=http%3A%2F%2Fwww.google.comTo check for tampering you look up the id and tracking code and set count++ if they match a record. The code doesn't even have to be unique.

Oh, and you should track which email they came from too. So that's two identifiers.

You have to put the email address into the link they click, or else some kind of identifier that you relate to their email address (eg, random code or ID number).

You didn't give the the "empid" ID your code expects.

Then you need to account for the "websitename". Best would be rebasing the site into that folder (ie, setting the DocumentRoot to be /path/to/websitename) or else you'll need to track that value somewhere and make sure you output it every time you generate URLs. Because you can't do relative paths (eg, just "post/12/postname") all the time: on the /websitename/post/12/postname page, trying that link again would take you to /websitename/post/12/post/12/postname.

You have to change your own links so the second form is what you should use - not the post.php one. 1. The link should be absolute, so /post/12/postname (note the leading slash) 2. Your RewriteRule requires a trailing slash so either you remove that or you put the slash in your URLs If you still get an Internal Server Error, try Options +FollowSymLinks -MultiViews

You can't magically recreate the currency_code, q, price, and totlday from just "/hotel_details.php?hotel_id=278482". This is one of those times where you don't use URL rewriting. Is it possible to generate/query for q programmatically so you don't have to put it in the URL?

You can make it not show up by checking to see if the line is "empty" and not showing the data if it is.

ginerjm is correct. $games is itself the [0] => SimpleXMLElement Object ( [@attributes] => Array ( [eid] => 2015010301 [gsis] => 56492 [d] => Sat [t] => 8:15 [q] => P [htn] => Pittsburgh Steelers [hnn] => steelers [h] => PIT [hs] => 0 [vtn] => Baltimore Ravens [vnn] => ravens [v] => BAL [vs] => 0 [n] => NBC [rz] => 0 [ga] => [o] => 1 [gt] => WC ) )part of the dump. htn and hs and vtn are all "attributes" of $games, and you access each one individually with array syntax ($games['htn'], etc). <g htn="" hs="" vtn="" />For ->htn->hs->vtn to work, htn would have to be a child of $games, hs a child of htn, vtn a child of hs, and so on. <g> <htn> <hs> <vtn /> </hs> </htn> </g>[edit] Casting to string, as with the (string)$g["eid"] in my earlier reply, is because those values are actually SimpleXMLElement objects. Not strings. They can become strings easily with a cast or when a function tries to treat the value as a string.echo is the latter case. You can echo those values without problems not because they are strings but because each SimpleXMLElement object is being automatically converted to a string. echo gettype($games["htn"]); // objectKeep that in mind because it trips people up when suddenly PHP complains that a value they thought was a string was actually an object the whole time.

They use URL rewriting. Exactly how depends on the servers they use in the background: Apache or IIS or nginx or whatever.

You should spend some time learning to read dumps like this. SimpleXMLElement Object ($xml is a SimpleXMLElement object [gms] => SimpleXMLElement Objectwith a "gms" child [g] => Arraywhich itself has a "g" child that is an array [0] => SimpleXMLElement Objectof more SimpleXMLElement objects [@attributes] => Arrayand each element in the array has attributes [eid] => 2015010301such as "eid". foreach ($xml->gms->g as $g) { echo (string)$g["eid"];

Not "implement". The operating system has already implemented all that. BSD sockets are how an application developer accesses that implementation. The PHP folks took that, made their own similar API, and exposed that to PHP developers. So when you use PHP's socket functions you invoke PHP's own socket implementation which then invokes the OS's socket implementation. Depends what you mean? The lowest level is in the operating system and you don't do that. Next up is typical compilable-language code, like C/C++, which lots of people do. If you make anything there then it would be, like, to abstract out some of the work (eg, bind and listen at once) or to be cross-platform compatible (eg, use winsocks on Windows or BSD on Linux).

system() only returns to you the last line of output. Maybe that line is empty? Try exec and its second argument.

Something is not adding up. Either your script will execute the echo and you'll get output, or PHP will stop earlier and issue an error or warning message. I suspect it's the latter. Maybe you don't have mysqli installed. If you're not seeing a message then your php.ini settings are not set correctly. Use phpinfo() to see what your error_reporting and display_errors settings are, and while you're there make sure it mentions mysqli.

You do realize you just asked "is there any reason to use these things besides when I'm forced to use them"? You could do a lot of stuff with the raw sockets but yes, when possible it's better to stick with the more abstracted, higher-level approaches: cURL, FTP functions, etc.

You aren't using mysqli properly and that's probably why. Assuming that the username and password you entered are actually correct, of course. 1. Don't use mysqli_real_escape_string() with prepared statements. 2. fetch() does not return an array. 3. You have to bind variables to the result, like you did with $username and $password, and fetch() won't work unless you do that. While I'm here, 4. Don't change PHP settings in your code. Do it in the php.ini itself. 5. !$_POST[*] will make PHP complain if the * does not exist in $_POST. 6. It also does not allow the value "0", which is unlikely yes but you should still not disallow it. 7. Don't store passwords in your database without using password hashing. You need to learn about that from someplace that talks about the password_hash() function. 8. Don't trim() the password. Maybe I want there to be a space at the beginning or end! In fact don't do anything to the password at all (except hashing). 9. Keep in mind that num_rows only works if you (a) call $stmt->store_result(), which you should do, or (b) have fetched rows. There are other things too but let's just take one step at a time. <?php // php.ini now has the settings // * error_reporting = -1 // * display_errors = on // * memory_limit = -1 if(isset($_POST['submit'], $_POST['username'], $_POST['password'])) { session_start(); if($_POST['username'] == '' or $_POST['password'] == '') { echo "Please make sure you enter both a username and password!"; exit(); } $username = trim($_POST['username']); // it's okay to trim() the username $password = $_POST['password']; // it's not okay to modify the password $stmt = $conn->prepare("SELECT user_level, active FROM usrs_usr WHERE username = ? AND password = ?"); $stmt->bind_param("ss", $username, $password); $stmt->execute(); $stmt->store_result(); // retrieve all the results $userlevel = null; $active = null; // you aren't actually using this value anywhere... $stmt->bind_result($userlevel, $active); // $userlevel gets the `user_level` value, $active gets the `active` value $stmt->fetch(); if($stmt->num_rows > 0) { if($userlevel == 1) { // $userlevel was modified during the fetch() $_SESSION['user_level'] = 1; $_SESSION['active'] = 1; $_SESSION['loggedIn'] = 1; echo "<meta http-equiv='refresh' content=0;admin.php>"; exit(); } else if($userlevel == -1) { $_SESSION['user_level'] = -1; $_SESSION['active'] = 0; $_SESSION['loggedIn'] = 0; echo "<meta http-equiv='refresh' content=0;banned.php>"; exit(); } $_SESSION['user_level'] = 0; $_SESSION['active'] = 1; $_SESSION['loggedIn'] = 1; echo "<meta http-equiv='refresh' content=0;index.php>"; exit(); } else { die("#~ Username or password is incorrect ~#"); } } ?>

Okay. Do you have any code yet? What is it? Is there a problem? How is it not working?

HTTP, right? It's how the web works: I send a request to you with what I want and you send a response back. Email? SMTP, more or less. Less transactional and more conversational than HTTP where I connect to your SMTP server and we exchange information, including the email content itself. DHCP and DNS? Packets fly around the network with tidbits of information, to and from the various computers and routers connected to it. All that happens over sockets. "BSD sockets" are basically the API to the operating system's TCP/IP/etc. implementation, and it's so common even Windows supports it. Right. "IP" isn't so much an IP address as it is an interface. For example, you can bind to the IP address corresponding to your wired Ethernet port, or to the IP address used by your wireless card, or to localhost. Or to all of them indiscriminately. You can't bind to someone else's IP address and magically receive their traffic. As PHP exposes a socket API to you, yes: you can connect to anything you want at any time and as long as your script is still running you can let anybody connect to you (except on ports SOAP is a protocol in its own right but it isn't the full story. It piggybacks on another protocol, like HTTP: regular web stuff except the request and response bodies are XML with a defined schema. I could write the XML down on a piece of paper and give it to you and that would still be SOAP, with the "another protocol" being reading and writing. Correct. They're just connections that enable you to send and receive data. The format and structure of that data is up to you and whatever you're communicating with.

The browser doesn't know that "www.pchl.org" is supposed to be a domain name. It thinks you have a directory with that name. Use absolute paths but without the domain name. With a leading slash. Repeat that for, well, pretty much every single link and URL you have. Tip: don't upload stuff until it works. Get yourself a development environment so you can see all your stuff running beforehand and fix any problems before you let the world see them.

Alright, let's backtrack some. Are you sure you have PHP installed properly? Naming your files with a .php extension? If you do a View Source of the page, do you see your PHP code?

Find your php.ini and change a couple settings within: error_reporting = -1 display_errors = onThen restart Apache (or IIS or whatever) and try your script again. See any error messages?

The code that does the email is near the top. You put the check near the bottom. It's not going to happen in time to do anything useful. The best thing you can do is restructure the code so that it's easier to work with. Do a series of checks for various types of errors and keep track of them as you go. If, after all the checks, there weren't any errors then you can send that email. It will also help cut down on how many levels of if blocks you nest together. if form was submitted { errors = array() if name or email is empty { add error message about filling in the required fields } if email is not empty and it does not match your regex { add error message about the invalid address } if they did not pass the captcha test { add error message about failing the captcha } if there were no errors { try to send the email. if successful { show the success message } else { show the failure message } } else { show the errors } }

It will recognize them because they're using the same "single username"... Regarding session IDs and the cookie containing that ID, it's the same thing as with your site A: they're different sessions with different cookies. The two sessions simply happen to be referencing the same account - as if they had the same value for $_SESSION["user_id"].

...Are you talking about deliberately reusing the same session for the same logical user even if they're on separate devices? I thought you were asking about something else. Please don't do that. The session should not be a place where you store temporary data. I don't want my sessions to be the same everywhere I go.

I believe you are. The session ID is stored in a cookie, right? Either the cookies are being shared in the two windows or they're not being shared; if shared then the windows will be using the same session (which is generally what happens), if not then there's no risk of accidentally "reusing" cookies from the other window.