requinix

I disagree about the "this is more of a PHP question and not really a SQL question" part. That's more like it. It doesn't matter who executes a query. What matters is who you entrust to maintain data integrity: do you want your application's code to do all the work, or do you want your database to do all the work? Programmers typically prefer the former, DBAs typically prefer the latter. Both have advantages and disadvantages. My preference: do it in code. It's highly visible, easy to change, and with proper modelling needs only be implemented in one place in code.

PHP only executes on one server at a time, so it doesn't matter if there's more than one server running this code. So basically, I'm saying these things like "put the file in one specific location" and "if you stored the location somewhere then look up that location again later" and you're saying those don't work. That's a problem because you don't really have any options besides that. Something has to give.

Umm... So, like, you'll have a file in /thismonth, and then move it into /lastmonth, and then move it into /soontobedeleted? Don't do that. If you want files in a directory according to the month, use a directory name for the month. Like "november-2015" or something. And then don't delete it later. If you really do have to delete it, delete the directories from 2+ months ago. Now, you say that you know where the files went and that you store that location to retrieve it later. What's stopping you from retrieving it now?

So there's S.us, www.S.us, and www.PL.com. Those work. PL.com does not. It's like I said: www.PL.com is using the right certificate which is why it works. However PL.com is using the [www.]S.us certificate. Using Chrome, I get the warning, click the "Advanced" link, and it says Make the PL.com site use the exact same certificate information as the www.PL.com site. Telling us a site because it's having problems, and especially because someone asked for it, is not advertising It's more about posting links in places where they don't belong.

Well, perhaps you could stop putting these files all over your server and pick just one place for them. Path is known at creation time? Good. Path is only known at creation time? Well then the file just got lost because there is literally nothing else that knows the path to the file. So you should probably record that path somewhere during creation so you can retrieve it again later.

"Accessible online" as in "online somewhere that is accessible by me". A shorter way of saying "is this on a website somewhere that I can enter into my browser and visit in an attempt to look at the certificate myself so as to give you a straight answer instead of telling you various things to do".

True, you can't really detect it as an ongoing activity, but you can detect it when it first starts: both users will be using the same session ID. At that moment you can force the second person ("second" being whoever did their page request after the other person) to be logged out. If the good user wins then the bad user is logged out and their attack failed. Of course if the bad user wins then the good user is logged out. Given how a session hijack should be a very uncommon occurrence, logging out both sessions would be best: in the former case, the good user would get logged out too - they'd be a bit miffed but can log in again while the bad user is left behind. Consider a session "chain". Chains relate different session IDs together, and each regenerated session ID gets the same chain. When a session hijack happens, there are two users with the same session ID for only a moment, but they'll both be using the same chain from that point on. 1. User A makes a request with session ID #101 in chain #501. Good. Response is session ID #102 in chain #501. 2. User B makes a request with session ID #101 in chain #501. Bad. User is logged out, chain #501 is flagged, they begin chain #502. 3. User A makes a request with session ID #102 in chain #501. Chain is flagged, user is logged out, they begin chain #503. 4. The two users are now on different chains. Only the good user can log back in again, and logging in is the only way someone can prove ("prove") they're the good user. Better to be miffed than have their session compromised. You could delay logging out user A until user B successfully logs in, but that requires the user logs in again and maybe they don't want to.

To clarify "concurrent session", I meant concurrent for a particular session ID. The only way that can really happen is if one browser grabs a copy of the session ID being used by the other browser. Short of some sort of browser-sharing sync thing that I've never heard of, this would probably only happen maliciously. Don't prevent concurrent browsing via two different sessions for the same user. As in, the user logged in twice. So don't restrict a user to one particular session.

The chain file connects your certificate to a trusted authority. You probably have the right chain file. The problem is you're using a certificate for [www.]site.us when you need one for [www.]site2.com. Can't use the same cert for both domains. You really sure you're using the same cert for both? It's additive. One is a bit verbose, two is somewhat verbose, three is very verbose. Yeah: the certificate does not cover site2.com. Like I said you're apparently using the site.us cert. Are the sites accessible online? That's the easiest way.

Check your certificates. Or if they're both online somewhere then we can see them. You should probably clarify what exactly the "error regarding ssl by the browser" is.

But how PHP know which session it should use? The browser has to tell it somehow. Sessions are controller by a session cookie (by default named "PHPSESSID") which contains a session ID (a random value). PHP gets the cookie with the request and loads the corresponding session data. Stealing a session is a matter of getting that session cookie and setting it in your own browser. PHP itself doesn't know the difference because all it has to work with is the session ID. That's why an application needs to verify session data: record IP address, user agent, stuff like that, in the session and then verify it with each request. Given what I just said about session IDs, this statement does not make sense. Depending on your application you may need a few things: 1. The session ID regenerates frequently and the old session ID is invalidated. This prevents concurrent browsing (eg, by the user and an attacker). 2. The session ID doesn't last long, depending on what kind of activity you expect from a user. Long enough that a user doesn't get logged out just because they stepped away from the computer, short enough that it's not feasible for an attacker to simply store the ID somewhere and use it later. 3. You may need persistence with a "remember me"-type token, which can partially identify a user. And SSL for everything, of course.

That would be because the "site2.com" hostname doesn't match the "www.site2.com" hostname in your certificate. You should be able to get a cert with both names in it. I don't remember the correct terminology but you specify one as the primary name and the other as a secondary name. Fun fact: up until relatively recently (a couple years or so?) https://amazon.com would present the SSL warning. Someone else had that problem too, forget who it was.

I dunno. echo? print? Mobile app? You decide. That would be why I suggested it.

The publicAddress and clientIdentifier are attributes on the . (string)$xml->Device["publicAddress"] (string)$xml->Device["clientIdentifier"]I don't know where you're getting the created time from but use date to make it more readable.

Use like you expect. However your emails have to be sent as HTML, which basically means formatting everything in the email as if it were HTML. Preferably with and and s and such. Once you have the HTML markup correct (you can send yourself test emails to verify that), make whatever you use to send emails send them as HTML. If you're not sure about how to do that, we'll need to see the code that does the actual sending.

Right. Do not redirect, make sure your website doesn't have the domain name hardcoded anywhere, and make sure your web server is configured to show the same site/virtualhost for all four domain names. Mind the SEO impact, though. If all four websites show the exact same content then they will all be punished for it in the search results. To be frank, what you want to do is a bad idea.

Order does not actually matter. What did you have that wasn't working and what do you have now?

\r and \n are easier than the \u syntax, but they'll be interpreted by Javascript and you'll get those characters inside the actual string. Escape the backslashes like "\\r\\n".

$entry is only an . There is no and such in it. You have to go down into the to get those. foreach ($xml->entry as $entry){ $Fnum=$entry->content->{'filing-type'};

There is a way to do it as you describe, so if you want that solution for academic reasons there's that. However it uses references (PHP does not have pointers but references are close) and I try to avoid references unless I know my audience (eg, coworkers) will be comfortable working with them. For normal code I would go with either a) The recursive version, as posted by Barand, or b) A loop-based version where you construct the array backwards, as in array() array('key3' => array()) array('key2' => array('key3' => array())) array('key1' => array('key2' => array('key3' => array())))

"The file input"? rename (which does moves too) Figure out the path to the file in directory A, figure out the path you want it for in directory B, and pass both to rename().

Okay, you got the "and a description of what's going wrong" part but you forgot about the "post the code you have". No, that's milliseconds. Probably to do with timezones.

So if you go into a MySQL client program (like phpMyAdmin) and execute SELECT * FROM reactions WHERE topic_id = 1then you only get three rows? Dump out or log the value of $row2 somewhere. If it shows three rows then you're looking in the wrong place, and if it shows more than three rows then Doctrine is doing something spooky.

Should be pretty straightforward: take the lines that deal with hours/minutes/seconds, create a duplicate fourth line for the hours, and make sure you get the math right. Example 1: <span class="hour">00</span> <span class="min">00</span> <span class="sec">00</span>becomes <span class="day">00</span> <span class="hour">00</span> <span class="min">00</span> <span class="sec">00</span>Example 2: var hoursContainer = $(container).find('.hour'); var minsContainer = $(container).find('.min'); var secsContainer = $(container).find('.sec');becomes var daysContainer = $(container).find('.day'); var hoursContainer = $(container).find('.hour'); var minsContainer = $(container).find('.min'); var secsContainer = $(container).find('.sec');Go ahead and give it a shot. If you have problem, post the code you have and a description of what's going wrong.

Opinion? You should have upgraded YEARS ago. Because 5.2 stopped being supported YEARS ago. No updates since then. Not even security updates. Who knows how vulnerable the application is! It will take time and lots of testing but it needs to happen: upgrade to PHP 5.6. There are migration guides available to help with the process.