Hot answers tagged web-development
It's dangerously easy as a programmer to start thinking that every project you encounter could and should be done better (read: rewritten) because it doesn't correspond to your vision. We've ALL been there. You look at code and your mind just goes into "what's wrong with this"-mode, instead of focusing on what's right about it. If you start plucking away ...
No, they're not. The purpose of auditing is to determine who did what in the past. The current data is irrelevant for this purpose, but you will need to record which data changed - there's no point in saying "user Dave change the person table" without saying what he changed. This information doesn't have to be recorded so formally though. You might like to ...
webSocket is implemented in browsers (not in the underlying OS). It is built on top of TCP/IP which comes from the OS. You can see which versions of which browsers support webSockets here:http://caniuse.com/#feat=websockets
You're on the right track, but missing one key point: All validation/authentication must be done (or double-checked) by the server, because you cannot trust the client. Maybe you already had this in mind, but it's worth stating explicitly. And yes, you definitely need to do both 1 and 2. In principle the logic for 1 and 2 should be exactly the same. A type ...
... table in my database named "users", which has their username/password/mail etc, Of course you mean that you're storing the "hashed" or similarly calculated value derived from the user's chosen password. How do I best store a users status? I would go with an Integer value in the users record, which is a foreign key to a (tiny, little) look-up ...
I agree with you, storing the status as integer will be enough. And I would prefer store it in different table, let's say user_status, since it will be updated frequently according to user activities.
For casual protection, you can hash some identification fields (including the ID) and include the hash in the page. When the page is posted, you hash the fields again, and compare them with the hash stored in the page. Make sure it's a salted hash so that it's difficult for the attacker to recreate the hash algorithm and make their own fake hash. For ...
The users table is definitely the place to store it. Note that if you use MySql (and possibly some others?), you can also use an enum, so that you can be sure that the value that you write is in range, and you can refer it to it legibly in your application's code (e.g., onLine, instead of 1).
This is what a conventional rails controller would look like: class HeroesController < ApplicationController before_filter :authenticate_user! before_filter :user_only def index @heroes = current_user.heroes.find_by_level(params[:level]) end end Controllers should map to resources, and your controller is returning a list of heroes. ...
Only top voted, non community-wiki answers of a minimum length are eligible