Grow your CSS skills. Land your dream job.

Try out my first PHP web app!

  • __
    # July 31, 2014 at 9:27 am

    Do you mean “bigger” by more work or more users?

    Definitely “more work.” If you’re lucky (and good), “more users.”

    there are over 50 new users signed up on there?

    Two of them are mine. But I have noticed spam messages on your “forum.” Weed, penny stocks, someone’s blog, various nonsense comments and XSS/SQL injection attempts. When you have an unchallenged, unverified registration system, you’ll get a lot of members who are there for the sole purpose of spamming (automated or otherwise).

    On the plus side, this means that you’re getting traffic… so it’s a success in that sense.

    # July 31, 2014 at 11:36 am

    XSS/SQL injection attempts

    The JS was me. Just checking his security.

    __
    # July 31, 2014 at 12:15 pm

    The JS was me. Just checking his security.

    hehe, yeah, I did one too. Also tried basic SQL injection on the login form.

    # July 31, 2014 at 6:42 pm

    Did the SQL injection attack that you attempted work? Also, from here where do you guys think I should go? I was planning on working out all the kinks in my login and registration forms before moving into the deisign part of the site. I have people registering under the same username as other people and gaining access to their account, and people who are trying to register getting error messages when there should be none. So that is my priority right now. Any suggestions? You guys have really been a great help and I want to thank you!

    # July 31, 2014 at 6:48 pm

    @un-traq-ed @chrisburton
    Another question, do you think I should be using seperate databases for my registered users, the forums, etc? As of now I have all of my websites data stored inside one database, and I will admit I think it is a little un-organized. What is usually best practice when building a site like this?

    # July 31, 2014 at 8:14 pm

    I have people registering under the same username as other people and gaining access to their account

    That’s a real problem. How are you setting up users? There should be a unique identifier for them. Why are you not checking if a user exists? That should determine whether the data is stored on the database or if they need to choose another username as it has already been taken.

    Another question, do you think I should be using seperate databases for my registered users, the forums, etc?

    I don’t see why you would need multiple databases off the top of my head. You should however separate the users from the forum data into two tables.

    __
    # July 31, 2014 at 9:11 pm

    Any suggestions?

    Without knowing what you did in the first place, no. As I mentioned earlier, it should not be possible for these sorts of things to happen: unique identifiers should be unique, and the database should reject duplicates.

    Did the SQL injection attack that you attempted work?

    No. But I didn’t persist; I just tried a few common, superficial attacks.

    do you think I should be using seperate databases for my registered users, the forums, etc?

    No… in fact, that would probably be counter-productive.

    …I will admit I think it is a little un-organized.

    That isn’t good. How is it organized now? what does you schema look like?

    # August 1, 2014 at 7:42 am

    @un-traq-ed

    Well, whenever someone registers a new user account. A new table is added to the database and the table is named whatever the username is. Inside the username table there is a messages and ID row. This is where the personal messages are stored. There is also a ‘users’ table where each username and password are stored which is checked on login. There is a forum table which stores each forum post, who posted it and the date it was posted (thinking of adding time). Lastly there is a comments table where the comments are stored for the forum posts. Writing it out now It actually seems pretty organized.

    # August 1, 2014 at 7:58 am

    @un-traq-ed

    It’s @traq.

    So you’re not checking to see if a user exists? What if a user created a duplicate of an administrator account?

    # August 1, 2014 at 8:44 am

    As of now, no. I just competley forgot. But I will throw in an if statement and make sure the user doesn’t exist. I’ll do that later today. Shudnt be a big deal to implement

    # August 1, 2014 at 8:50 am

    Well, whenever someone registers a new user account. A new table is added to the database and the table is named whatever the username is.

    No! Do not do this!

    You need to create a pivot table, or assign foreign key to corresponding tables. So you’ll have something like this:

    __
    # August 1, 2014 at 10:20 am

    A new table is added to the database

    Right — if you mean what you actually said, no! do not do this!

    You should create your database schema exactly once. No site functionality should require creating new tables in the database. Follow Alen’s example of using foreign keys to show relationships between data: that’s exactly what they’re for.

    Further, if you want the usernames to be unique, checking from within your PHP scripts is the wrong approach. For example:

    1. New user A asks if the username “Clancy” is available. PHP checks, and it is.
    2. New user B asks if the username “Clancy” is available. User A hasn’t actually registered yet, so when PHP checks, the username is still available.
    3. User A finishes registering, and now has the username “Clancy.”
    4. User B finishes registering, and now also has the username “Clancy.”

    This is called a race condition. It’s not PHP’s job to prevent this sort of thing;* it’s the database’s job. username should be a primary key. This way, user A would get the name Clancy, and user B would get an error on insert.

    * now, if you want to use PHP to check username availability for convenience —so you don’t waste the user’s time on names you know are already taken— that’s great. That’s entirely appropriate.

    It’s @ traq.

    hehe, I actually changed it so I wouldn’t get as many @ mentions in my inbox.

    Writing it out now It actually seems pretty organized.

    If you’d like further database advice, please share your table schemas (use show create {table-name-goes-here}).

    # August 1, 2014 at 10:21 am

    What is better about the image you showed as opposed to my method? What are the benefits? Thank you!

    # August 1, 2014 at 10:30 am

    It looks like the photo of the DB example you showed is what I have for my comments on the forum section. Each forum has a specific Id and the comments are added to the database with that specific id of the forum post the were posted on. When the post is clicked. Php pulls all comments where the ID of the post = the Id of the comment.

    __
    # August 1, 2014 at 11:31 am

    It looks like the photo of the DB example you showed is what I have for my comments on the forum section

    Alen’s example was just to demonstrate how to use foreign keys to associate (in this case) comments with the users they belong to. It’s not a complete design for either table.

Viewing 15 posts - 31 through 45 (of 432 total)

You must be logged in to reply to this topic.

*May or may not contain any actual "CSS" or "Tricks".