- This topic is empty.
-
AuthorPosts
-
August 26, 2014 at 12:56 pm #180741
Alen
ParticipantI suggest you watch following
August 26, 2014 at 1:17 pm #180748nixnerd
ParticipantI suggest you watch following
This is a pretty good video. Very helpful OP.
August 28, 2014 at 9:53 am #180939__
ParticipantI really wanted to make this site useable to people
don’t take this the wrong way:
start over.
I think I mentioned somewhere earlier in this thread that, when you’re learning, it’s not uncommon to reach a point where you realize that the way you started doesn’t work with the way you learned, so you’ve got to scrap it and rewrite. This might happen several times. I scrapped my first CMS-like project four times (and it came out “okay” …nothing like it would be if I wrote it now). That’s okay.
If you decide to “go for it,” I’d recommend designing (in the “engineering” sense) your site at a fairly high level first: without writing any code, get as specific as possible describing what features you want, how they interact, how they work, and so forth. The more stuff you can plan for, the better it will all work off-the-bat.
When you do start writing code, start with “general” code instead of specific things. A lot of tasks you do will need to be done in several places (e.g., reading query results, staging content for templates, etc.), so try to write that code in a general way that you can re-use, instead of writing similar code over and over.
August 28, 2014 at 6:08 pm #180970ParticipantIt wasn’t a full-on CMS, but it had a lot of CMS-like functionality. It’s not online anymore. I’ll see if I can find any of it (and if I can post anything without breaching NDA).
More recently, I’ve been working on a framework, which I will probably be rewriting after I’m done with my current node project.
August 28, 2014 at 8:40 pm #180982ParticipantNot exactly. “CMS” implies a degree of flexibility and general-purposeness that you’re not really (or, don’t seem to be) aiming for. Page creation/management, for example; full front-end administration, and so forth.
Which is not to say that I think it is lacking. What you’re building now is plenty to keep you occupied.
September 4, 2014 at 2:21 pm #181717Soronbe
ParticipantIs this something that would work effectively?
Yes, and it is what you should do. Be aware however that htmlentities will solve a lot of security issues on it’s own already.
September 4, 2014 at 2:26 pm #181718ParticipantIn general, I prefer the philosophy of escaping on display: leave everything literal until right before it needs to be escaped/encoded.
This gives you more flexibility with usage (for example, if you use
htmlspecialcharsand then store that result in the DB, you won’t be able to use that bit of content in plain-text environments like text email or JSON).It also tends to put the escape/encode function closer to the spot where the output is used, which can help you keep track of what is “safe” and what isn’t.
You should also consider using some sort of naming convention for variables that hold content: for example, when I have content that might include HTML, I use a
htmlsuffix on the variable name. Content that should not be html must be escaped before being combined with content that does. Basically, it helps you keep track of things.$article = 'This is some text that talks about <html>.'; $articleHTML = '<article>'.htmlspecialchars( $article ).'</article>';September 4, 2014 at 2:36 pm #181719ParticipantThat’s quite correct, although you will have to consider stuff like SQL injections.
September 4, 2014 at 2:52 pm #181720ParticipantThat’s quite correct, although you will have to consider stuff like SQL injections.
Yes; didn’t mean to gloss over that. Prepared statements FTW!
September 4, 2014 at 7:10 pm #181738September 4, 2014 at 8:43 pm #181741ParticipantCould someone tell me why prepared statements are so much better?
http://mattbango.com/notebook/code/prepared-statements-in-php-and-mysqli/
tl;dr: the database knows better than you do.
September 4, 2014 at 8:50 pm #181742chrisburton
ParticipantSeptember 4, 2014 at 9:13 pm #181744ParticipantWell, that article mentions three main advantages:
- Prepared statements are more secure.
- Prepared statements have better performance.
- Prepared statements are more convenient to write.
Security:
Prepared statements allow you to send your SQL instructions in one part, and the data in another. SQL injection attacks are all about tricking the DB into doing something by confusing data with instructions. Using prepared statements makes this impossible.Performance:
Using prepared statements allow the DB to analyse your SQL and build an execution plan for it before actually doing it. This has the advantage of only happening once, even if you execute the statement many times. The separation of data and instructions can sometimes even allows better performance with single-use statements.Convenience:
You can write your statements more clearly, without worrying about having to use double-quotes vs. single-quotes or concatenate the SQL around calls to escape functions and “imagine” what the finished query will look like. Easier to read = easier to understand, fewer mistakes.September 4, 2014 at 9:18 pm #181745ParticipantGotcha. I wasn’t sure exactly what you were referencing. Thank you.
September 6, 2014 at 9:13 am #181901ParticipantDo prepared statements cover things like htmlenteties() and striptags()? Or only protect from SQL attacks?
Prepared statements are for the database. They take the place of trying to escape all your inputs manually (e.g.,
real_escape_string, etc.). You still need to validate that the data is what you expected.It has nothing to do with how you display info to the webpage, so
htmlspecialcharsand friends are still needed. -
AuthorPosts
- The forum ‘Back End’ is closed to new topics and replies.