I am wanting to create a user block I have the button
<a type="button" value="1" name="block" Cursor="pointer" href="blockuser.php?uid='. $data['id'].'">Block</a>
But I'm wanting to know how best to do this with PHP, Ajax and either the users table or a separate blockuser table. So when I click on block I cansend the value 1 to the database with the users id and stop them from veiwing my whole profile with a switch and visa versa.
I will then go on to creating a block list with the ability to unblock this user at any given point, if users so wish.
Privacy is a must! Thanks for any help given.
The only real question in your question is whether to create a new table for this or not, as the rest is a group of very straight-forward tasks for the technologies you mentioned.
Personally, I would opt for simply adding a column to the current users table and filling it with a comma delimited list of User IDs which you could simply search for a user ID within. This has the advantage that you'll only need to run one query vs. the two which would be required to check the block list and then get the viewed user's info in the two-table scheme.
Adding users to the blocklist is trivial (append a user id and perhaps a comma), and dropping the user from the blocklist would simply require splitting the blocklist, removing the proper user ID, then rebuilding the list by joining with a comma.
Also, this is only useful to implement if you require authentication to view a profile, and even then one could circumvent such a system by simply creating a new account.
On each row in the database where you store the profile information (perhaps the members table?) you can add a row called "blocked" which stores the ID numbers of the members that are blocked. I would separate these numbers using semi-colons personally and $blocked_ids = explode(";",$blocked) to get each blocked ID. From there you can check if the person is to be blocked from the profile by using: if(in_array($user_id,$blocked_ids)), if that value is in the array, prevent the profile view.
Hope this helps you, any questions just comment below
As far as the database goes, I would probably do it like this - create a table specific for blocks. Two essential fields would be the id of the blocker and the id of the person being blocked. This means that if one person blocks two users, he'll have two entries in the table - don't try creating one SQL field to act like an array.
Currently, you're setting up to use a standard request to a PHP stage with a $_GET parameter. There's nothing majorly wrong with that, but if you want the whole operation to happen without your page refreshing, you can use Ajax. With jQuery:
$.get("remove.php", { uid: "someID" } );
Related
I'm currently working on a website which will have many users on it. These users are stored in a table with each having a unique id. The website will contain projects that the users can complete and these projects are stored in a separate table with unique id's as well.
I need to make the users have a page they can view which will display a list of all the projects they are currently working on.
To do this, I am going to set up another table in which each row will have the user's id as well as the project's id that they are working on. All of that will work alright but I would like to allow users to cancel their projects if they please. I am aware of how to do this, but I have read that deleting rows directly from a php script is insecure so the user used to access the database from PHP does not have 'DELETE' permissions. I am wondering if I should just delete rows at will when a user specifies which project to delete or if I should just have another field and simply mark each user-project row as being 'cancelled' in another field so I can work with them myself.
What you should do is, for maximum security is, have a parameter in the database table called "isActive", or something of that nature, that is a BIT data type to represent a boolean. If that boolean is false, then do not delete the project from the database, simply hide that tables data (do not display it on the site, but keep the data stored in the databse). That way, not only is your database secure from malicious users who would like to destroy data, but projects can also be "re-instated" if they wish to re-instate it. If the project sits around for a certain period of time, say, 14 days, just have the server delete it, not the user, if you wish. This worked for me in the past.
Hope This Helps!
The most common approach to this problem is to have a field in the table that can be used to mark a record as deleted. This would be the only access the general user would have to the table as far as deletion goes. Some people also have a full delete, which states clearly that it will never be accessible again after the operation is completed.
Personally, I prefer to retain full delete permission to administrators allow the user to only mark records as deleted. If you're concerned about space, add a last accessed field as well, and schedule at set intervals a call to perform a full delete on any records that are marked as deleted and have not been active for a certain amount of time.
I'm working on a PHP/MySQL application that allows for organization members to be maintained within the database. Currently, upon clicking on a "Add Member" span, I insert a blank entry into the database and return the created ID to PHP. Upon receipt of a valid ID, the application user is redirected via jQuery to an edit page that refers to the newly-created member.
As far as I can tell, this has the following advantages/disadvantages:
Advantages
Can instantly associate purchases/payments with a member upon submitting a jQueryUI dialog, since I already have the ID of that member.
Unifies what would have been separate add/edit screens, so easier maintainability on my side.
Disadvantages
There is a high possibility that I will have stale entries. That is, someone could click on "Add Member" multiple times and not save the new page, therefore causing entries to remain blank.
Not able to enforce as many constraints in the table, since I need to be able to accept NULL for all of the columns.
Am I thinking of all of the scenarios/advantages/disadvantages? Should I make a separate page for adding members, or is it better to accept the stale entries, and possibly add a few checks when I fetch all members to make sure that I'm not displaying a stale entry?
My database function for adding members currently:
public static function addMember()
{
$q = 'INSERT INTO ' . MemberTable::TABLE_NAME
. ' (' . MemberTable::ID
. ') VALUES (null)';
try
{
$db = new DBConnection();
$toRet = $db->execute($q);
}
catch(Exception $e)
{
error_log($e->getMessage());
$toRet = -1;
}
if($toRet > 0)
{
DBSystemEvent::logMessage("Added new member with ID $toRet");
}
unset($db);
return $toRet;
}
EDIT 1: After rereading the question, I need to clarify that members and users referred to in the first paragraph are different. Users refer to the person logged into the application. Members are not able to log into the application. This is similar to a hospital application (patients may not log in or edit their own information; only application users such as nurses or doctors may log in and edit information).
EDIT 2: While none of the given answers completely fit my problem (since I may have to insert into the database without knowing an ID), I decided to accept an answer based on how my question was worded (since making it any more specific may cross into too-localized territory).
It's a common problem - you need to know the ID before INSERT, but it's known only after. So there is only one adequate solution: use GUID (http://en.wikipedia.org/wiki/Globally_unique_identifier) instead of autoincrement ID. Generate guid from PHP code, for example com_generate_guid(), and do not preINSERT empty rows at all. And make relations between tables with GUID fields.
It's little bit unclear to me what exactly is the workflow of your site.
If user comes to you page then I assume that he must login from where you get his ID. If he is new user then he is redirected to userdata.php?id=0 where he enters his data. After submitting you should check if $id=0 and if the user with the same username/id/.. exists (SELECT... WHERE ID=xxx) and warn user to change his username. If no match is found then you can do INSERT and obtain the new ID.
If in future user wants to change his data then after login you can direct him to userdata.php?id=123 (where 123 is his ID). Then you can check if $id>0 and do UPDATE.
If you can, switch to postgresql. This will allow you to use a sequence to provide you with a unique ID without entering empty entities into you database.
Funny enough one of my clients is using the same approach you haven chosen and so far this lead to a lot of maintenance and work load overhead to weed out the empty entries from the db.
If you cannot use a database that offers sequences consider using an otherwise empty table which only atomically gives you unique ids. That way you can already start using the id to prepare relations on the client side and then enter them in bulk into the db when the member is finally created.
I find several partial solutions in answers on this question, but common answer seems to be absent.
So, I have a table users with columns user_id, user_name. On each static page of website I want to display all user names of users who currently view this page.
Should I have a table views with columns user_id, webpage_link?
If yes, when I shall update data in column webpage_link? How to connect code from following answer with mysql database Is there a way to detect if a browser window is not currently active? ? (If it is ok for this purpose.)
To make updates very often is not very good. So, the user can view several pages (for example, in 2 or more tabs). What type of webpage_link column shall be in this case?
With every http request, you get a $path variable. if you also have a logged in user, you can store which page this user requested last (e.g. in a table like you described, but only storing the relative path).
You update this information on a per-request-basis in some sort of front-controller. (just make sure you put it where it is called for every authenticated page). When the users session times out, you remove the row of that user from the table.
this case is a little more difficult. you could store the last n pages/paths the user has requested and leave the rest as above. You don't have to change the table structure for that, just allow for multiple rows per user. (the combination user_id+path should be unique, though)
Hope that helps to get you started
For instance , in my system i allow the user to create a list and add some information into the list eg. name , address, phone...
And after create the list, it will be inserted into database, and in the page the admin can delete the list
The problem is when user editing the list, the admin deleted the list, then what will happen?
The only way is to check the database again before the edit submit to the database. However, If there are a lot of form, a lot of input, how can i check each field , there is a lot of job if i have to check every field that is concurrent.
I am using php , mysql and pdo for query
Thank you
Well why wouldn't you simply check if the row exists in the corresponding table using it's primary key (id) ?
Basicly, you cannot avoid that situation. While the user edits the form, the user cannot find out if the form has been deleted.
One solution would be to have a flag up once the user starts editing the records that should prevent anyone from editing at the same time/deleting at the same time. Once the user submits the form, then the flag should be back to original value, so that other users/admins can edit/delet those records.
There is a second solution of using a service and check from time to time in the user's page via ajax if the records are still there, but if you have alot of inputs, that can be a little cumbersome to implement.
Basicly, you need to create something that resembles a transaction, aka. lock the records that are being edited. Be very carefoul, since you can end up with alot of locked records. You need to implement a time in which the user needs to finalize the "transaction". If there are locked records beyond that time, unlock them automaticly. Also beware of the fact that the user might exceed that time and you need to handle that situation also, since you will end up in the same state as your original problem.
PS: also you need to beware of informations that have been edited while the user was editig also, since those informations would be lost. For the edit part, i think i would go for a hashing approach to check the state before editing with the state after editing. from this point on, it's up to you to decide what to do.
A customer wants a button that says "Relate" that would be kind of like the Like button in Facebook. It would show how many people clicked the button inside an article. Is there an easier way to do this besides creating a table in MySQL and use PHP?
I suppose you could use a CGI script written in bash that read/writes a plain text file that stores the click count. But one way or another you're going to have to have some kind of server-side handling and data storage. Doesn't have to be PHP/MySQL, but you'll have to use SOMETHING.
If you want to use data gathered across multiple sessions by multiple people, you're going to need to store that data. Whether you store it using databases, textfiles, or carve it in a tree is up to you.
Yep, instead of creating a new table, just add a column likes INTEGER(11) to articles table. Whenever someone clicks the "relate" button just add count by one.
You may also want to disable button after user has clicked it. You may want to store the info liked:article_id in cookie to make sure user do not adds fake "relates", unless he clears cookie. But tracking logged in user is different (but more appropriate) game.