scootstah
-
Posts
3,858 -
Joined
-
Last visited
-
Days Won
29
Posts posted by scootstah
-
-
Get rid of the absolute positioning on the span and set the li to center its content with flexbox.
-
Remember to never retrieve data from $_POST or $_GET as they are deprecated.
You're probably confusing $_POST with $HTTP_POST_VARS, which is deprecated. $_POST and $_GET themselves are not deprecated.
Grabbing data directly from $_POST or $_GET is fine in most cases, as long as you sanitize/escape before you use it elsewhere. You can't just fetch your data from a single filter_input at all times, because sanitation is a contextual thing. What makes sense for one system might not make sense for another. For example, SQL injection makes no difference when outputting to HTML, and XSS makes no difference when saving to a database.
-
You change the query to use an ORDER BY clause on the date field.
-
You create an "action.php" file. And then you use $_POST to get the data.
-
That's why every programmer/administrator in their right mind uses a defense-in-depth approach: You need to take care of the OS and the webserver and the applications and the database system etc.
Every programmer/administrator in their right mind (hopefully) isn't using Wordpress.
You can (and should) take the proper precautions on the server-side, but if you have a vulnerability in the code that lets you drop to a shell, there's a good chance you're going to get pwned.
I don't care if there are valid reasons for giving Wordpress write access to PHP files. Considering the security record of this software, I wouldn't do it, especially when it's a private website which can easily be maintained by hand.
True, I guess I wasn't talking about Wordpress specifically anymore.
-
i offer some dynamic content (nothing important). the main goal is that the user only has to click 1 button to retrieve 1 line of code (for simplicity sake).
In that case you are limited to the data that the client chooses to send you.
but ask user for website details is too easy too cheat.
There are ways to prove the user owns/has access to the domain they enter. If you don't do this, you're allowing the client to cheat in a much easier way.
-
There may certainly be a vulnerability in your code, but the real issue is that your PHP scripts are writable. An application must never be able to change arbitrary files on your server, no matter how broken it is.
If there is a problem in the code that: lets you upload malicious files instead of say images, has LFI/RFI vulnerabilities, has eval(), etc, then you basically have access to the server itself. Even if Apache is unable to write to any other file except one vulnerable one, you could still potentially exploit something like a privilege escalation vulnerability on the server.
There's valid reasons to allow the application to write PHP files. Caching is a big part of that, as well as configuration management, etc. A vulnerability in systems like that would be bad news.
-
This happens pretty often with Wordpress. You need to keep it updated.
If you're not using Wordpress, there are numerous things you could do wrong in your code to become vulnerable.
It could be a server vulnerability, or it could be a software vulnerability.
-
2
-
-
You could have them enter more information when they generate it, and tie that information to the ID.
-
Well sure, you could write something to reduce noise. You'll probably be unable to get it perfect though, and it's a destructive process. Personally I would find an existing library to use, even if it's not written in PHP.
-
The Javascript doesn't work because you're not returning the expected JSON response from your PHP script - you're just returning HTML. My proposed PHP script determines whether the request came from AJAX and returns JSON if so - otherwise it returns HTML.
The modifications I made to the PHP script returns whether the request succeeded or not, and includes your message strings. I'm not sure how you think it is identical, they are very different.
-
I see. The crosses in the Apollo 16 image are called fiducials and are a permanent part of the image. With the right skills they are easy enough to remove in Photoshop, assuming you have the rights to do so.
I'm not sure about the second one - just looks noisey/grainy to me.
-
Cron doesn't understand anything, it just executes the statements it is given at the specified intervals. If your command works when executed manually, it should also work when executed from a Cron job.
What I said about making sure the Cron owner has write permissions was specifically for the log file path that you add to the end of the command. The Cron owner would need write permissions for that log file.
-
You could do this, if you think it's cleaner. I believe this is what Jacques1 is suggesting.
$(document).ready(function(){Otherwise, you could use a Promise. Then you could do this:
function socket_open(port, https, success, failure){
var location = window.location,
host = location.hostname,
protocol = "http";
if (https){
protocol = "https";
}
var url = protocol + '://' + host + ':' + port;
console.log(url);
$.ajax({
'url' : url,
'success' : success,
'error' : failure
});
}
socket_open(8080, null, function(){
console.log('successful');
}, function(){
console.log('error')
});
});socket_open(8080).then(function(){
console.log('successful');
}); -
I already explained that in detail in my other post. What are you having trouble with?
-
You should look at the responses in the other tabs when you send a message. Is the server sending anything?
But you're going all about this the wrong way. Don't use AJAX for real-time applications. You're making like 3-4 HTTP requests at least every second. You're basically DDoS'ing your own server.
You should use WebSockets instead, which creates a persistent TCP connection between the client and server. Whenever one person creates a chat message the server will push it out to all of the connected clients. This is a much more efficient approach, and this is the way that every client/server chat system works.
-
-
This "overlay" sounds suspiciously like a "watermark". If you have the rights to use the image, try contacting the author to see about altering the original.
-
Okay, so you didn't modify the PHP to give Javascript what it needs. See my other post.
-
Can you post the Javascript and full PHP page please?
-
You're worried about typos, but not worried about accidentally mixing up the order of parameters? It would be a very easy thing to do with more complicated queries. The negligible amount of extra typing is not an excuse to forego readability/maintainability. If I open an application for the first time to track down a query, I don't want to spend time counting ?'s and trying to figure out where data should be getting inserted. I want to be able to identify what is going on as quickly as possible. If I see a named parameter called ":categoryId", it's pretty reasonable to assume that that is where the "categoryId" value is getting inserted.
-
2
-
-
Which of these do you consider more readable and maintainable?
INSERT INTO person (firstname, lastname, email, age, gender, height, weight, location) VALUES (?,?,?,?,?,?,?,?); INSERT INTO person (firstname, lastname, email, age, gender, height, weight, location) VALUES (:firstname, :lastname, :email, :age, :gender, :height, :weight, :location);
If you have complex queries with dynamic clauses and stuff, it quickly becomes chaotic with ?'s.Either way, you still have to know the order
There is no order when using named parameters. You can bind values in whatever order you want.
-
That kind of data can not be stored in the database
What? Of course it can.
You can never implicitly trust your data source. A database is in fact a data source. You should treat it the same as if you were fetching the data from a third-party service.
EDIT: And just for the record, you can remove the last character of a string with rtrim(). But as other's have pointed out that is not the correct approach.
-
Your schema is a many-to-many relationship between games and categories, meaning that many games can have many categories. In your screenshot though you just have a dropdown, as if to suggest that any game can only have a single category. If that's the case you can remove the JTBL_Game_Category table and simple add a Category_ID field to your TBL_Game table.
As an aside, I recommend you use named parameters in PDO instead of ?'s. Once you have a bunch of parameters it's a huge pain to keep track of the order of them and such.
$sql = "UPDATE JTBL_Game_Category SET Category_ID=:newCategoryId WHERE Game_ID=:gameId AND Category_ID=:categoryId"; $statement = $db -> prepare($sql); $statement -> execute(array( 'categoryId' => $categoryId, 'gameId' => $gameId, 'newCategoryId' => $newCategoryId, ));
How to Create a "action.php" page for HTML Form?
in PHP Coding Help
Posted
https://www.codecademy.com/tracks/php
Start here.