requinix

NULL represents a lack of information. This would be a good time to use it. In my opinion, you should have another means of knowing whether the match has been played - deciding that a match has been played should not depend on there being a score recorded. Perhaps a status ENUM (eg, "scheduled" vs. "played") or a played flag (false/0 vs. true/1).

Keep-Alive is potentially a relevant concept here: messages are periodically, on the order of seconds or even minutes, exchanged between the hosts simply to confirm that both ends are still connected and talking to each other. If you're normally exchanging messages constantly then you don't need this. TCP already has a mechanism to re-send messages so you don't need to duplicate that particular aspect. What you need to worry about is whether the recipient is in the process of responding; with your cross-client messages you also need to think about whether your connection to the server is fine but its connection to the other client has been broken. I would use Keep-Alive (eg, ping/pong messages) between each client and server. If a request is lost then either (a) the next Keep-Alive will fail and the connection should be severed, or (b) the Keep-Alive continues and you... well, you just keep waiting (unless you want to add a sort of timeout/TTL concept to your messages). A Keep-Alive can also provide a way for the server to track which clients are still connected, so if a cross-client message needs to be sent and the recipient is down then the server can immediately reply, or maybe spool the message waiting for the problematic client to reconnect. Of course TCP has Keep-Alive too, so you don't necessarily need your own version, but if it's not much overhead to implement then I like the idea of knowing not just that the connection is working but that the applications on either end are still working too (and not, say, stuck in an infinite loop somewhere). If the peers are potentially doing long-running operations then this is probably not a good idea, because regardless of what React hides under the hood PHP is still single-threaded. Regarding the excerpt, keep in mind that JSON-RPC is designed as an underlying transport mechanism for the exchange of messages. A read-through of the OSI model will help. Technically OSI deals with the actual underlying networking principles, and everything you're doing is part of the application layer, however since you're working with a communication protocol you can draw analogies between OSI and what you're working with. JSON-RPC is mostly the transport layer-side of things. It deals with the message format and how they're exchanged between peers. That part of the spec is talking about what the layer should do when the connection is severed, and is necessary not just because closed connections can happen but because JSON-RPC isn't actually the transport layer (TCP is) and is thus susceptible to what the real layer does. To communicate the connection problem with the higher layers (ie, your application) JSON-RPC 1.0 mentions exceptions. These aren't "errors" that it otherwise mentions least of all because errors are exchanged between peers and thus are useless if the connection is closed. Thus I assume they mean that an exception is raised towards the application; it had used JSON-RPC to send a request and thus it needs to receive something as a response. Ideally each request sent would have logic for a response and logic for an exception, for example try { $response = $this->transport->sendRequest($request); // handle response } catch (\TransportException $te) { // handle exception }AJAX works similarly, with the technical advantage that is uses an optional error callback instead of forcing a stack-unravelling exception. You could (and with React, probably would) do the same. The second half of that excerpt deals with an unusual situation where the client and/or server can't understand each other, so closing and re-establishing the connection brings them back to a hypothetical handshake stage (which JSON-RPC doesn't actually have...) - or in other words is the "turn it off and on again and see" approach.

Still wanted the full HTML but at least I see the problem: You're using a bunch of position:absolutes everywhere and that can easily mess everything up. Specifically, you've done it on the .container and aren't positioning those relative to a parent, which means they'll all observe the implied left:0 top:0 and move to the top of the document/page. Looks like you want to use that to position the child elements? Do position:relative instead: it allows you to position children absolutely (relative to the container) while keeping the element in its original location.

The problem is trying to do two loops at once: the first over $sorters and the second over the counts. Can you get rid of $sorters and just use the query? It will include the list of countries automatically so...

Use Javascript to set (and possibly get) a cookie.

The PHP code is irrelevant: it happens on the server and your problem is on the client. What is the full HTML of an example invoice? If you don't want to include the CSS then fine, but when I can't reproduce the problem with just the HTML then I'm going to ask for it too.

Actually it could explain it. Just copy the markup into a post.

Could be any number of things, none of which have to do with PHP. What's the full markup? Are you applying any CSS rules that affect how elements are positioned?

None of this matters if you can't use HTTPS. You could have a 4096-bit rotating API key if you want, but if it's transported over plaintext HTTP then it's all pointless. No HTTPS is a deal breaker for having anything that could resemble security on this server. The fact that it's on shared hosting is already a sign that your client doesn't actually care about keeping their system safe. Your job is now to call them on their bullshit.

Sounds like client-speak: management got scared by something and wants to know that there aren't any l33t hackers watching their super-important traffic. And since Loo said "client" it sounds like a small- to medium-scale contracting thing. If the advisor said "public/private key" then... well, that's not terribly helpful. Everything serious in security uses asymmetric keys nowadays. Given the technical context of Loo's post, I'd interpret it as doing something like using certs on both sides of the SSL socket - not a full-blown PKI infrastructure. But maybe we're talking about an unknown number of clients, in which case my solution would require some way to have the authority automatically sign certs without [much] developer involvement. Or on the other hand, maybe mere SSL would be enough to assuage fears. Some more information about the nature of this system would be nice...

Moved. Maybe if I make the warning scroll too... Making a text file and putting it in a database doesn't make sense. Just put stuff into the database. You can have your PHP get what's there, allow for editing, and have it put the new version back. Don't know where to start at all? No offense but Google is probably your best bet. You're the one who knows how you learn best, be that tutorials or videos or online courses or whatever. Look for stuff that involves "PDO".

The scheme you need is called X.509. You know how SSL/TLS uses a certificate on the server to verify identity? X.509 is the same thing but applied to both the client and server. You don't have to do any PHP to make this happen, depending how paranoid you want to be. 1. Create a certification authority; essentially a set of files (not a server) used to sign certificates. Like Verisign or Entrust or others, this authority acts as an entity that will be trusted by both parties to validate certificates. Creating your own means you can dedicate this authority to only signing certificates used in this exchange and simultaneously require that only certs signed by it are allowed; any ol' Verisign cert won't work. Back up those files somewhere safe: they're the keys to someone participating in this exchange. 2. Have the client and server generate their own certificates, then use the authority to sign them. Simply having a certificate proves the client is trustworthy, but you can also use the information in the cert to further confirm their identity (see #5). Client: 3. Have cURL perform validation. This includes both verifying the server cert (against the custom authority) as well as providing the client cert from #2. Server: 4a. Configure your web server with the server-side cert generated in #2. This is your standard SSL stuff. With Apache there are a handful of SSL* directives to enable this. Note that doing so means this HTTPS endpoint won't be easily browseable by a regular user: though it will have a cert and thus be secure, the browser will complain that the authority is not known/trusted. If this will be an issue then you should use a separate HTTPS endpoint away from the regular :443 one. 4b. Also configure it for client verification/X.509. A few more SSL* directives in Apache are relevant here too. This should involve indicating a trusting authority: that would be the one you did in #1. With this in place, the server will verify the client certificate against your authority, and only certificates signed by it should be permitted. 5. If you want to identify the client then it depends on your web server. Apache can set environment variables which will be available in $_SERVER; grab the email or DN or whatever from there and do what you want. Alternatively, you can have it pass the entire certificate and use PHP code to validate it manually (likely with openssl functions). This looks like a good reference.

If you're having problems putting that code into functions then we need to see the version where you put that code into functions.

Mapping tends to be a thing when you're working with a framework that already has its own model system - and mapping practices. If I were implementing this idea on my own then I would keep it simple: form model's properties match the form fields and it has load/save methods to import/export a database model, or models as the case may be (and obviously another method, likely inherited, for populating from request data).

Having to maintain a mapping is cumbersome. Do you have any attachment to being able to separate the model from the form? Would it be so bad to consider the model (this model) as a "form model" and have form fields map directly to object properties?

You need to learn about HTTP. This thing seems a reasonable explanation of it. Once you know HTTP you can send requests and receive responses over that socket.

1. You can't session_start() if there has been any output. Move that to the very top of the script. 2. If you want to remember the values (and want to use the session for it) then you actually have to put the array into the session. The logic for #2 is simple: if there is an array in $_SESSION already then use that, otherwise use the default ABCDE array. Manipulate that array however you want, then put it back into $_SESSION. Give that a shot. If you have problems, post your new code.

Yup, that's it. You can still use debugging, but you cannot do anything that would cause the properties in the mysqli object to be evaluated.

It's possible that the act of dumping $db will reset the errno, as "all functions that have to ask the server for information reset [the errno] if they succeed", and the mysqli class has a number of dynamic properties. Try dumping just $db->errno.

It needs to be on. If it keeps turning off, I don't know, but it does have to be on for this to work.

Advice: any time you do a foreach by-reference, unset the variable after the loop. Or don't use references at all. Otherwise you might accidentally use the variable later in your code and create some really unusual bugs. And please, indent your code. foreach($_SESSION['golf_entrants'] as &$row) { if ($row['id_code'] == $id) { $row['entry_name'] = $name; $updated = true; } } unset($row);

I can't think of a single site, PHP or not, that has users and does not expose the user ID in some way. Picking basically the first link I can find on these sites: - StackOverflow: "Rana Ghosh" is #6162401 - MSDN Forums: "Imtiyazk" is 370588b4-fbbe-45a5-b066-bfb0fa31debf (that's a GUID) - Slashdot: "Aethedor" (first comment) is #973725 - Wikipedia: "Segehelmus" is #21621158 - Twitter: Rachel Maddow is #59437078 - Facebook: MrBean is #17774451468 Or maybe you would like to pick a site for me to check? The ID number (or GUID) is irrelevant. It doesn't matter if anyone knows it.

I've done that in a handful of cases where I needed sessions but wasn't sure if it had been started yet (and there wasn't anywhere that would authoritatively start them). It could be an indication of poor design, however.

Then that's the way you have to do it: unset whatever in $_SESSION directly. When you unset($msg) all you're doing is unsetting that variable.

You can't really do it. Not like that. What problem are you trying to solve? Why do you need to unset a value this way?