Jump to content
Larry Ullman's Book Forums

Larry

Administrators
  • Posts

    5413
  • Joined

  • Last visited

  • Days Won

    155

Posts posted by Larry

  1. Also, you make a good point about having to edit all the index.php files if there is a change. That being the case, would you recommend having an index.php file in each folder that simply includes (in the programming sense) a top-level script? And then maybe, you would have a function in that top-level script that each index.php file calls and supplies the necessary information as an argument to get the correct data from the database? I mean, I suppose that's what you already said, but just want to clarify.

     

    Yes, exactly.

     

    On another note, I have been wondering about this for a while, but if you have an .htaccess file controlling access to a Web folder, why do you recommend placing the files outside of the public Web directory? Does it really add extra security?

     

    No, it's an either/or. If the folder isn't in the Web directory, then there's no need to use an .htaccess file on that directory (because it's not Web accessible).

     

    If, for example, all the images for a particular gallery where in a Web folder, and that folder also included an index.php script and an .htaccess folder, wouldn't that be plenty secure? Also, when you use the mkdir function in PHP, the default permissions are chmod 755, which would prevent the writing/deleting of files by non-admins, right?

     

    "Plenty secure" depends upon the site in question. 755 means that only the owner can write to the directory.

     

    That makes sense, in the same way that a proxy server might be used to hide the actual IP address, etc., but...well, okay. I suppose if you really need that level of security, sure. Thanks, Jonathon.

     

    That's the fundamental thing about security: if you need that level. There's no right answer, there's only more secure and less secure.

     

    A proxy script can do more than what you think, though. You could use a proxy script to limit access to only registered users or to count how many times a resource has been requested.

     

    As * Hartleysan said, I`m not sure why this is necessary. It just seems more logical to have all the artists media kept within the folder for his

    gallery. If done outside the artists`s folder, then you get into the added complexity of linking a specific artist with his/her image files

    (adding a new table to the database, writing more code, putting more demand on the server, etc...). What do you think about Hartleysan`s

    suggestions?

     

    It's not a matter of "necessary", it's a matter of "warranted" or "appropriate".

     

    I didn`t even think about this one! Thank you so much Larry!

    Hartleysan thought that including a simple function call in the index.php file to a "createPage()" function in an upper-level script would be a

    good way to do this and I agree! All links shown in the index page would call upper-level scripts to create the new content (i.e. gallery pages)

    without the user ever leaving the folder/index.php page. Does that sound like a good idea?

     

    Yes.

     

    Hartleysan suggested the same thing about using the folder name, and it would certainly work fine, but I just feel that using the artist`s ID would

    be a more direct and less error-prone way to make a database query. Querying the user table by "folder_name" just seems like a half ass

    workaround to the way it ought to be queried (i.e. by user_ID). I look at it like this: Imagine that we all live in a small town. Everybody in the

    town has one car, and they are all different makes and colors. Would it be more logical to ask "Who owns the red Porch 911?" , or "Who owns the

    car with license plate # 1967825?" The last question is far more accurate/efficient from a database point of view. The problem is how to get

    access to this user_ID unless it is embedded in a variable within the index.php file. With that scenario I now have to open, write to, and then close

    the index.php file before writing it to the artist`s folder every time a new account is created, which does create more work!

     

    You should never make the primary key value (from a database table) publicly available. Definitely not secure. To improve upon your metaphor (and I like a good metaphor), the real suggestion is that everyone knows everyone else's social security number, which would be bad.

     

    * Hartleysan and I both live in Japan and are good friends. We often talk about various web projects and code problems.

     

    Excellent. Nice to "meet" you.

  2. I noticed in your book that you use

    quit();

    to exit the program. This NEVER works for me, I get errors actually in php when I use that, but

    quit;

    works fine.

     

    To exit what program? Because I don't think quit() exists as a function in PHP.

     

    Also when you move up a folder you use

    a single ./ instead of ../

    why is this?

     

    Yeah...no. To move up a folder, I use ../

    ./ moves into a folder, starting from the current directory. These are not equivalent.

     

    I am just curious, because for me those two things as written in the book don't work for me at all.

     

    If you can provide specific pages where you're seeing these things and are confused, I can help explain what's going on.

     

  3. Okay, even if XAMPP comes with JSON installed, and I'm not sure what that means in this case, you still need a parseJSON library installed. And your script needs to include the parseJSON JavaScript library and then call the proper method of the proper class. Don't get distracted by the header(). Right now, if you want to use parseJSON(), you need to focus on choosing, installing, and using a proper parseJSON library.

  4. To be clear, it's not a full MVC approach, it's a partial one. The PHP scripts are the controllers, the HTML scripts are the Views, and the stored procedures are, in theory, the Models. The stored procedures as Models is actually the point where it doesn't really adhere to tight MVC patterns.

     

    If you were to do an OOP implementation of MVC, you'd write the Models and Controllers as classes, separate classes. An instance of the Controller class would create an instance of the Model class as needed.

  5. - What are some best practices/good security measures for implementing something like this?

     

    Um, be extra careful about validating the uploaded files to make sure they're of acceptable types. A proxy script, and blocking direct access to the subdirectories (using .htaccess or the like) would be even more secure.

     

    - Should the images be stored in the artist`s folder, or should they be stored outside the web directory?

     

    I normally try to put all writable folders outside of the Web directory.

     

    - Would you create a modular structure for the index.php page (so that the user never leaves the artist`s folder), or would you have

    it redirect to other scripts on the top level of the site?

     

    The problem is if you ever need to change that index.php page. If so, you'd need to do so for all X users. It'd be better to use top level scripts.

     

    - When a visitor visits the artist`s index page (within the folder), how would you link the index.php file to the particular artist`s data,

    by the folder name in which it resides or by a variable stored within the index file?

     

    I would think by the folder name, which the index file passes to the root level scripts that do the actual action. You want to avoid as much work up front as possible, and as many later edits as possible.

     

    - And finally, when should the folder be created, before or after the artist creates his profile? I don`t want to run into a situation

    where the directory was created, but the database wasn`t updated for some reason, or vise versa!

     

    I'm not sure how to answer this one. I suspect it does't matter so long as you have checks that would delete the directory should the database insertion fail and vice versa.

     

    Sorry for all the questions, but this type of layout is quite new for me.

     

    No problem. That's what the forum is for!

  6. Hey Jonathon,

     

    Well, you could have installed Yii yourself, but perhaps they maintain the framework version if they do it. As for the caching tools, support for those is preferred in order to offset the performance hit required by the framework, but that is only an issue if your site is really active.

  7. It's not a big deal to convert to the older MySQL functions, you'll just need to do it. If you're in a situation where you don't need dedicated (or, really, that good) hosting, then I wouldn't worry about the performance issues. Yes, the MySQL Improved functions should perform better and support other features, but it doesn't sound like you're in a situation where you need to spend money to make that happen.

×
×
  • Create New...