Leaderboard

See this reply regarding session_start()

Thanks to both of you. You have really helped me along the way with the database. Barand got me started with his ideas, and then gizmola came up with some add-ons that were in my head as add-on features to enter into the database later. It was the addition of gizmola that was missing to get this to vote. With the table berthBoat I will easily be able to add these extra features afterwards. gizmola and Barand, you are talking about something when you talk about how the system in the boating association is. It is thus the case that there is an association with permanent members where the membership is year-based, but continuously until the member terminates the membership. That is, you receive an invoice once a year. This applies to both support members who are without a boat or a member with a boat and berth. Possibly in anticipation of berth becoming vacant (then the member is listed in a waiting list). I will probably need some help with this waiting list later as well, but it will come when the rest of the system is ready for it. As it has been suggested from their side until now is completely in my street for how the system should be, what data should be stored and retrieved etc. Just like a history section about each member. The plan is for each note to be saved each year before it is deleted. It will not be deleted permanently, but transferred to a separate table for a register for posterity, but which will not have a negative effect, only storage of what a person has done, etc. if you understand what I'm talking about. A lot of this is in PHP scripting as well, these are some of the plans for my boat association's system. I will also include some functions with regard to invoicing directly from the member list. This is far into the future. I'll now give you both a small donation. It's not much, but that's what I can do now for this time (gizmola) I did not get to donate anything to because he does not have a paypal account). Hope there is so much that I can get more help when I need it Barand. This system is becoming more advanced than first thought. Ideas are created as time goes on. Thanks for the help so far. P.S. What meens FUBAR?

Oh dear. A raw image from a camera is where it records, with its electronic circuitry, the "colors" of each "pixel" that it can measure. It records that in a file in the very most basic way that "pixel X,Y is color Z" can go. Raw image files are large because there's a lot of data. To deal with the file size, images are compressed. If I write "computer computer computer" that takes 26 characters, but if you and I agree on another representation of words, I could compress the message to something like "3x computer" and 11 characters. Lossless PNG images work the same way. I could compress it even further as "3x cmptr" (8 characters) by stripping out the vowels, thus losing some information but still leaving enough that you know what I'm trying to say; lossy JPEG images do that. That takes care of the image itself, however images have more information than that: GPS coordinates where it was taken, camera model information, etc. That has to be represented in a way that doesn't conflict with the image data. The easiest way to do that is to say, inside the file, "The next piece of information is the GPS coordinates: (...). The next piece of information is the camera model's name: (...). The next piece of information is the compressed image data: (...)." PNG and JPEG and such images dictate compression but they also dictate how those blocks of information are arranged, and software capable of reading them will know how to read each block - or perhaps how to skip each block it doesn't care about until it finds the one(s) it wants. The information in each block can vary: the GPS coordinates block may have two 32-bit floating point values for the latitude and longitude, the camera model name may be a string value, and obviously the image data is image data. Consider one of the simplest attack vectors: PHP code inside a string-type data block. I could take a real image, add a "camera model name" block, and specify as the name the string "<?php phpinfo(); ?>". That's perfectly valid to do. I could then take that image, rename it from bad.png to bad.php, and try to upload it. Unsafe image uploading code will attempt to read data about the image, discover that the file is a very legitimate PNG, and upload it to a location like /uploads/requinix/bad.php. See how it kept the same file name and extension? I could then go to the website, go to /uploads/requinix/bad.php where the site thinks is going to be an image, but the .php extension will be run as PHP code and I'll get phpinfo() output. You can protect yourself against those attacks by following best practices about file uploads - most significant being determining the appropriate file extension on your own instead of trusting the uploaded file's name to be correct. More complicated are attacks that target specific image parsing code. Not your website itself, but the software that knew how to read PNG images directly. I'm not going to go too deep into this because it's complicated. Remember the camera model string? There's one question about how it works: where does the value of the string end? The two typical answers are that the length of the string is included (so "camera model block" + string length + string) or that the string is terminated by a special character (like NUL \0). So what happens if you don't obey that rule? I might take that bad.png I created before, load it into a special editor, and break the string (by altering the string length value or by removing the \0). With appropriate adjustments I might be able to trick an image parser into doing things it isn't supposed to do. You cannot protect yourself against those attacks, practically speaking.