requinix

Your question does not make sense. Where is 1,2,3,7,8,9 coming from? What does this have to do with the code you posted, which clearly only tries to return true?

myMethod is supposed to be inside the class body, like with getProducer and ShopProduct. Buuut I'm pretty sure that whole class is just supposed to be a visual example. Not actual code you use.

It sounds like OP wants to call all three functions. Not just one of them.

I should probably read the rest of the thread, but I could imagine a legitimate use case: a third-party service that acts on behalf of some company but itself stays mostly in the shadows. Salesforce does it. Various payment providers and gateways have something like it (like the one my health insurance company uses). It makes sense for those services to be sending email that looks like it's from the hosted company rather than the service's own domain. With that said, those are the kinds of situations where the hosted company should set up emailing properly - by creating SPF/DKIM records to validate the service's mail servers (as providing email server information would be iffy). It's a concept that's so frequently abused but still possible to use legitimately.

Well-developed, free, open-sourced code that happens to do exactly what you want and precisely how you want to do it? If I put it that way, does it make it clearer as to why you haven't found it yet? HTML 5 has a drag and drop API you would use to get the file uploaded. Storing the file works just like any other file upload. Expiration is a matter of using a cronjob to run a script which finds and deletes old files.

Is this really a PHP question?

I wouldn't think there's anything wrong with it. May be suspicious, to the receiver. Consider putting some kind of notice within the email indicating that it was sent by you on someone's behalf. "Report abuse" kind of thing. If that even makes sense. I assume bigcorporation.com is the domain of the email who you're claiming to send as? This is part of spam filtering, and can easily get your emails filtered out, so if that's going to be a problem then you need to re-think what you're doing and how. Two things you can do to avoid it: 1. Send using the user's actual emailing service, which will require information they don't know and information they might not want to give you. 2. Set up domain verification. DomainKeys (DKIM) and SPF validation are the mechanisms for that, but to do verification the user needs to alter the DNS records for their domain to indicate that your email server is allowed to send emails on their behalf. In other words, you can't really do anything about it. With that said, there is a third option: 3. Don't claim to be sending from their email address. You'll avoid the verification problem because you're not attempting to act on behalf of anyone. Again, this may or may not make sense/be viable for your uses. A little notice at the bottom of the email, "This email was sent on behalf of from . Report abuse, etc." would be a good idea.

But wouldn't that mean the source you scraped from had "\E8" too? That would be odd. If not then there was a problem with your scraper...

This isn't the kind of stuff where you can copy some code you find online and have it up and running in an afternoon. It involves actual learning. And time spent learning. Are you willing to do that?

elseif($targetDate $targetDate will always be before (less than) $runningDate. Maybe you mean to use $time?

"No such file or directory" Obviously it's not talking about the file - that isn't supposed to exist yet. So could it be that the directory does not exist?

$link = mysqli_connect("", "", "", "");Besides not specifying a server host to connect to, the username to connect with, or the password for the user, all of which are BAD THINGS, you aren't specifying the default database. Either that table mentioned in the error message really does not exist, or you need to specify the correct default database when connecting.

All you have in that form is two textboxes. Are you really sure you need a preview for them? Whatever. Use two buttons in the form: one to submit normally, one to go to a preview mode. If the user clicks the preview mode button then you don't process the form like you would have but instead show the form information in some "preview" form or another.

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.