kicken

I have a function that I use so that you can still code like old school concatenation, but use modern binding. It goes a little something like this: function Parameterize($value, &$binds){ static $counter = 0; if (!is_array($binds)){ $binds = []; } if (is_array($value)){ if (count($value) == 0){ return 'null'; } else { $allParams = []; foreach ($value as $v){ $allParams[] = Parameterize($v, $binds); } return implode(',', $allParams); } } else { if (is_bool($value)){ $value = (int)$value; } else if ($value instanceof \DateTime){ $value = $value->format('Y-m-d H:i:s'); } $param = ':param' . (++$counter); $binds[$param] = $value; return $param; } } You'd then use it like: $min_price = 10; $max_price = 50; $featured = 1; $binds = []; $sql = ' SELECT * FROM projects WHERE min_price >= '.Parameterize($min_price, $binds).' AND max_price <= '.Parameterize($max_price, $binds).' AND featured = '.Parameterize($featured, $binds).' '; $find_records = $db->prepare($sql); $find_records->execute($binds); $result_records = $find_records->fetchAll(PDO::FETCH_ASSOC); I find it keeps things easy to understand and helps reduce the code footprint while still keeping things safe.

Friendly spiders such as google's will identify them via the User-Agent header in their HTTP requests. For example, google sends: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) This header is most likely how the forum is deciding if it's google or not. If you follow that link in the user agent header for google, they mention being able to verify an IP belongs to google bot by doing a reverse DNS lookup on it. Other spiders may or may not have a similar IP verification mechanism, you'd have to research them individually.

In general I'd say your common object should only contain the common properties. As such, your common object shouldn't contain any references to some other item-specific details. The reference to the common object should either be in the specific details or some linking table. Another way to look at it is, if your relationship wasn't one:one then you'd have to reference the common object from inside the specific object. Since in the one:one you could technically do it either way, might as well do it the same way in both cases for a) Consistency and b) Makes a one:one to one:many conversion later easier. So from what I understand of your gateway/devices situation, you'd end up with something like this: PhysicalDevice represents your Modbus/Bacnet/whatever devices that are pre-generated. These rows are essentially static and never changed. Then you have your Datasource, gateway, device one-to-one relationships connecting those all together. If your device needs to be using one of the physical devices you set PhysicalDeviceId, otherwise leave it null. Or if needed, break out the physical device mapping to yet another table. If you need to determine which physical devices are being used, just check if there is any reference to them in the Device table. Not sure if any of that will help with your real situation or not.

I'm not too sure what your going for with your gateways, devices, etc. If you haven't yet reached a conclusion to your problem, I'd suggest trying to refine the details on that some. As I understand it you have some AbstractDataSource type which is responsible for gathering data from somewhere and GatewayDataSource is a specific type of source. GatewayDataSource uses some sort of AbstractGateway to obtain that data (different specific gateway types exist). So it would seem at this point you have essentially - AbstractDataSource/GatewayDataSource: Requires a gateway instance so a foreign key is needed. You're unsure whether the foreign key should exist in the AbstractDataSource or AbstractGateway tables. - AbstractGateway: Might use a device so it should have a (NULLable?) foreign key to a specific device. You're unsure whether the foreign key should exist in the AbstractGateway or Device tables. - Device: Standalone object It sounds to me currently like your gateway and device object might be setup to be shared instances that different data sources just link to. If that's the case, then keep the references in the data source. Have your source link to both the gateway and device and composite them together as needed. If every data source gets it's own unique gateway, then you could instead link the source to the gateway then link the gateway to the device. This is the part of your post that is causing me issues trying to understand what kind of setup you have and thus how it should be structured. This implies to me your devices (and maybe gateways) are some kind of shared resource meaning many gateways may link to the same device so if a gateway is deleted it shouldn't be deleting the device as it might still be used by others (now or later). It might be helpful for explaining the situation to focus more on explaining how the physical networks your trying interact with work and what you need to do with them, rather than or in addition to the code your trying to write. On a side note to the evolved car/motor example (which doesn't seem like the same situation to me), in the past I've essentially made two relationships for such situations. 1) Car has some sort of CurrentMotorId foreign key that would reference whichever motor is currently being used by the car 2) Every motor has a CarId foreign key reference to indicate which car that motor was used in (either in the motor table or a linking table if motors are shared between different cars over time) Current car operation can be handled using the first relationship. Historical service data can be found using the second relationship.

If everything is working for you, then great, run with it. However, I'm curious if there's a particular reason you cant just add/remove your network_node entries as needed? You say every account has a specific number of them. That seems like a requirement best handled at the software level where these records are managed. In the database you'd just have nodes that are actually in use, but in the management UI you could display X number of nodes for the account at all times. If the user adds a network to the node, insert a new network_node. If they remove the network, delete the node.

Your code block is messy and doesn't make a lot of sense. For example, what is playServerURL()? Is that supposed to be where your ajax call is? Then why isn't it? What are those three lines of dots that are absolutely a syntax error? You need to post something more representative of what you have, not just random lines that show no structure and won't even compile. That said, you don't return data from an ajax call by using return because of the deferred nature of the ajax process. Either you use a callback function that then accepts the data (like how $.ajax calls your success handler) or you return a promise that can then have callbacks added to it and are run when the data is ready.

For PHP you can go to Settings -> Editor -> Code Style -> PHP and on the right there is a Set from... link. Click it and choose Predefined Style -> PSR1/PSR2 That'll give you a basic setup which you could tweak as desired. While your editing a file you can press CTRL+ALT+L to have it re-format the document according to your style settings.

Your problem is probably just that in javascript strings are not suitable for binary data. Javascript will convert the response to UTF-16 which will end up corrupting your MP3 data. You need to process the response as a binary blob instead of a string.

Your mime type is incorrect, there is an extra dash. request.setRequestHeader("Content-type", "application/x-www-form-urlencoded");

IE didn't handle <button> properly, that's why it wasn't used/taught so much I believe. Now that the browsers all seem to handle it properly it's more common. I almost always use <button> now days in my stuff so I can label buttons with an icon + text. That's not really related at all to the comment made. The current proper method being hypothetically deprecated in the future is completely different than using the old deprecated method now when a better method exists just because you're not familiar with the newer method. Especially when that newer method is not complicated to learn. If you want to use separate forms because it fits your situation better then fine. Sometimes multiple forms is easier to do. Just don't dismiss alternatives simply because they are new. In your situation I'd probably go for a single form and separate buttons. It's easier and less markup overall.

Your ideas regarding trying to limit accounts based on card numbers (particularly only the last-4) and track individuals by card numbers are fundamentally flawed. 1) Card numbers can be reused over time. Not sure how common it is or the time frames involved, but it's happened. So you might be inadvertently locking people out because their card number happens to match one used by someone else 10 years ago. 2) Only checking against the last four digits would have a very high collision rate giving you lots of false positives. 3) Services exist that let you create new credit card numbers on the fly. Someone could use this to generate as many numbers as they needed. These services exist specifically so people can use numbers unique to different sites to avoid hacking and tracking problems.

Try disabling xdebug.remote_connect_back, that is intended for when you can't set xdebug.remote_host to a specific IP. Also make sure you're configuring the correct PHP setup. The PHP run by apache and the PHP run on the command line can and usually do have different configuration files. If your only editing the CLI configuration but testing via apache that would explain things. Run your phpinfo() function by creating a page and loading it to check what configuration apache is using.

You probably saw the behavior you did due to using sessions. When you start a session PHP will lock the session data so that it's not affected by other processes. This lock exists until you either call session_write_close or the process ends. So if you're long-running process doesn't need to update any session data, call session_write_close prior to starting it. That said, lots of concurrent long-running processes could block a server. Your HTTP server will process each request using a thread or worker process (depends on the configuration). I'll only spin up a certain number of these based on the configuration and if that limit is reached it'll stop responding to requests. Your long-running processes would tie up some of these threads. The number of threads available on an actual server will probably be relatively high though, so unless you expect a lot of these processes to be running concurrently it likely won't be an issue. If the server is setup with something like PHP-FPM or a CGI setup though, the number of allowed PHP instances may be smaller. You limit would be the smaller of the the http server's limits or PHP's limits. If you want to keep your site responsive though, the way to manage that would be to offload the work to a background process so that your website can continue to respond to requests. The user would then go to the page which would trigger the processing and you would respond with a message like "We're working on your request, check back in a bit". When the process is complete give the user the results. There are many ways to accomplish this, such as using services like redis, gearman, beanstalkd, etc or simply adding records to your database and having a background service checking for new records periodically.

I'd say it depends on the type of book. For something like a technical reference that's marked up and linked properly then sure, online may be a better scenario as people would probably be less inclined to be reading start to finish and instead jumping around to the information they need or want. For something more story/native that's intended to be read front to back in order, I'd gather most people would not be reading it on a PC. Most readers I know either stick to physical books or their phones/e-readers. I'm not trying to sell stuff, but that's my general point of view on things as well. Most attempts at stopping piracy I've experienced are counter-productive. They don't do a great job at preventing piracy (someone breaks it eventually, and usually in relatively short order), but limit your non-pirating customers severely. For example pretty much nothing the movie industry has tried has worked for very long but their attempts prevent me from easily creating a digital copy of the movies I buy for use on my HTPC though, which is a perfectly legal and reasonable thing to do. In my opinion, the best way to try and tackle the problem would be to 1) Make sure your product is easy to acquire for those who want it (reasonably priced, no region locks, etc) 2) Monitor the web for pirated copies and respond appropriately when you find them.

I personally don't and haven't used PostgreSQL (most using SQL Server for work), but I see references to it enough that I would expect the community around to to be large enough that support shouldn't be a big issue. The [postgresql] tag on stack overflow seems reasonably active at least. Most of my knowledge about it is outdated at this point. I seem to recall back in my early days people recommending it over mysql because it had proper foreign key and sub-query support but mysql has since add both of those. I think I saw something recently about it having a json datatype, but might be mis-remembering. I remember that sounding potentially useful though.

Users being able to download the book for offline reading is probably an important feature that could make/break sales, so it'd be a good idea to support it I think. That also probably means providing PDF's. I'm not familiar with all the options, but I'm not sure there is much you can do to prevent someone from stealing a PDF. I think adobe's reader supports some kind of DRM system but not sure. Also not sure how that'd affect other readers. The only thing you could really do I think is monitor the internet for copies of the PDF and submit take down requests when it's found. I suspect you may be worrying about it more than you really need to. In general people aren't that prone to stealing stuff. Most people only resort to that kind of stuff if obtaining the item legally is made difficult (ie, too expensive, region locked, etc). The most likely problem you'd have is just people sharing logins or the pdf among their friends/family, which is something you could probably do even less about. If you could lock down the PDF in some way to a device or something, the user could just let their friend barrow their device. Like with the security stuff, it's all a trade off. This time between protecting your IP and ease of use. If you wanted to make them searchable, putting them in the database could help, but there are also other solutions for that. As far as the contents of the books go I don't really see any compelling reason to go one way or the other. It's kind of hard to provide much advice here without knowing more about what exactly your offering and in what way. For example if you are going to go the route of PDF downloads your database could just consist of some metadata regarding the files for your site to use, then a location to the file on disk for downloading. If you're going to go an HTML route with some templates, then storing the content in the DB may be easier and you could setup some kind of online editor where you could edit/create new content.

How are you referencing the mp3 files in your detail.php file? You should reference them using a domain relative URL (with a leading slash), that should remove any need for a rewrite rule for them. <audio src="/sf/sound.mp3">

That's the fundamental issue, and very problematic with any shared hosting solution. With shared hosting, the only real option is to store it in a file somewhere, and like with the sessions, if they run everyone's code under the same account then anyone with a site on that server could read that file and get your key. PHP running scripts under the same account was common back in the day when I used the occasional host, but it may not be anymore. You'd want to check with your hosting provider. If they do run your scripts under a unique account, and you're not overly paranoid you could possibly get by. With a VPS you can still store the key in a file for convenience, but since no one else is sharing the server you don't have to worry about someone getting in that way. Your worry here is from faults in the software you run that may allow someone to access the server, and that's pretty much a worry you'll have no matter what you do. Just keep things updated and audit your code to find problems. The more ideal solution is to require the key to be entered any time the system is started, allowing the key to be stored only in the memory of the system and nowhere on disk. Someone would have to be able to gain access to the system memory without causing a reboot to get your key at that point, which is harder to do. This kind of setup could be done with a VPS or dedicated server. If you're really paranoid, a dedicated server is best as a VPS could technically be paused and have a snapshot taken which would then contain your key. That comes down to trusting your hosting provider.

Everything is a trade off between security and usability. That's why things like cryptocurrencies haven't really caught on. The security on them is generally pretty good, coins can only be accessed using praticaly impossible to break private key. The usability is awful for the average person. Didn't back up your key and your HDD caught fire? Well, there goes your life savings up in smoke. The question is where do you want to draw the line, and that's usually determined by the risk and consequences of a breach. If you were running a bank, a breach would be bad news. In most sites though, a breach is both unlikely to occur and unlikely to cause major problems. So the question is where do you want to draw that line? I've known some companies that require you to email/fax a copy of a government issued ID to their support and they will only give you access to the account if the name on that matches the name on the account. That'd always be an option. Seems a bit overkill for a simple e-book store site imo though. Again, if it were me I'd probably solve the above two scenarios by just using something like having the person verify their billing details or some other bit of information. For example, "What's your First & Last name, and the last 4 of the card you used?" If they can answer that, it'd probably be ok to just assume they are the owner of the account and change the email. Practically, how likely is it that someone would contact support to try and break into a different account and actually know that info? Fairly unlikely. What's the worst that can happen if someone actually succeeds? They get access to someone else's books, and possibly inconvenience the real owner? Not that big of a deal.

If you're just using the default files setting, it's controlled by the session.save_path setting. You can check what this is by creating a page that calls phpinfo() and loading it up in your browser. You could implement a session handler that stores the session data into a database instead which could offer a little more control over the data access. However, if the different sites on the host all execute scripts as the same user then other users could still access your session data. Privacy and shared hosting are generally incompatible. If keeping the information protected is important, you should invest in some non-shared hosting such as a VPS or dedicated server.

If your goal is ease of use for the end user to maximize sales, then you could reduce the friction some while still gaining most of the benefits. As was mentioned before, don't make the verification required to process the transaction, but rather do it after the fact. There's really no need for the user to enter a code, most places just send a link with a unique code in the URL. User clicks the link and the email is verified. Show the user a notice on login that their email needs to be verified still, and possibly lock out their account until verification is complete after some time. If it were me, I'd probably have a process such as: User selects a subscription type Gather account & payment information Create account, send verification email Let the user access what they paid for. After 3-7 days, restrict the account if the email is still unverified. That works around potential email delays and gets the user to their content the quickest. You could do the double email field as an additional measure to try and catch people fat-fingering their email. In most cases though the user will probably enter it correctly, get the verification email, and click the link on their own time without issue. If the user does fat-finger their email (intentially enter an invalid one) they will get their content for a while, but then have to correct the problem. Allow a user to change their email if their account is restricted due to no verification. Depending on the level of security you want, maybe require the password as well to re-start the verification process. A third option to minimize end-user friction would be to let them use something like google, facebook or twitter to login instead of creating an account. A lot of people prefer that these days as it's one less account/password to have to remember. I know I personally am far more likely to hit the 'Login with Google' button than I am the 'Create an account' button.

I would, possibly. Depends a lot on what your trying to sell and how badly I need it. I've left quite a few sites that I otherwise might have given money too simply because they required me to create an account. IMO, the best sites are the ones that let you just "get your shit and get out", with an option to create an account later if you so desire. Most of the time I'm just trying to get one thing and have no intention of ever coming back to said site, so making an account is an extra step that provides zero value. If I do end up back at the site a second or third them then I may go ahead and setup an account. Another downside to requiring even email verification is that email isn't always nearly instant. I've had multiple times where a site sends me an email either for verification, password reset, whatever and ten minutes later I'm still waiting for it. Somewhere either on there end or at one of their providers the email got delayed. If I'm trying to go through your process and that verification email is lost/delayed any longer then about a minute, there's a high probability I won't bother finishing the process. Unless an accurate email/account is vital to the operation of your site, it's best to avoid such things if possible, leaving it to the user to decide if they want it's worth it to them to set that stuff up. All that said, if you feel such a task is necessary for your site or what to do it anyway, implementing the actual verification isn't all that hard. As I mentioned above, the best way would be to use some Javascript to trigger the email when they click the button. Using jQuery, such a script might look something like: Email: <input type="email" name="email" id="email"> <button type="button" id="sendVerification"> Send verification code </button> Enter code: <input type="text" name="verification"> $('#sendVerification').click(function(){ var email = $('#email').val(); $.post('sendVerification.php', {email: email}).then(function(){ alert('Email sent'); }); }); Your sendVerification.php script would then generate the random code and send the email. Store the code in $_SESSION and when the user submits the form you can check the code they entered against the code that was sent.

You should upgrade your PHP install. 5.6 is pretty old and outdated at this point, and is no longer receiving any kind of development work (security or otherwise). For the certificate, you can tell cURL what certificates to trust by setting the CURLOPT_CAINFO option to the name of a file that contains your certificate. curl_setopt($ch, CURLOPT_CAINFO, 'certificate.pem');

Your webserver is responding the the browser with a redirect (Status 302) so the browser is trying to follow that redirect. If you're creating a new resource you should be responding with status code 201. If you're updating an existing resource you should respond with status code 200.

Not always as good as I should be at keeping up to date on the latest PHP stuff. Having it at hand here might be kind of nice.