My doubt is quite simple probably, but as a first time for me, this things get confusing
My PHP code is basically a session based one where each person gets texts to display on their page once logged in, but each person gets different ones, and those are saved on a database with their names too
So I need to know how would I make the query on php to get the information belonging to my current user
Something like
if(user=="John"){
display(documents of John);
}
Of course "documents of John" is a field instead
But, hopefully you can get the idea
Thanks
use the user and run a sql query to get document from documents table where username = user. Retrieve the data.
You got the document related to that unique user.
Related
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
I am programming a Blog. I am interested how to add a counter to the side to see how many people read the different articles.
I understood that if you have a Website counter, than you would normally save the IP and the Date in the database so you only count the person once.
But how would I make sure that a person reading a specific article is only counted once for that article?
The database would turn very big if I would save each Visitor IP for each Article. It came now into my mind to maybe create a Session for every Visitor. Within this Session I save each ArticleID the Person read. So before I update the counter in the database, I check if it already exists in Session - if not increment counter and save in Session otherwise dont.
Is this the right approach or is there another way to do it?
It depends on which data you want to save. You can save:
Number of hits (count all people/bots/... who opened the pages), this makes fake impression of readers, because doing a refresh will count me twice.
Number of unique visitors, create a session for the user. and increment the counter only once in the session. This can be improved by setting permanent cookie, but looks like overkill for me. and by the way, I can open the article and don't read it!
Number of people interact with the article. You can put some javascript capture (mouse scrolling, clicks on article text, ...) , split text into parts with "read more" ... etc.
If I were you, I will name it "number of views", and use solution 2. And combine this with google analytics (or similar solution) to know more details about visitors.
Google analytics is better way
But if you want to do it by programming then follow the steps.
i) In your table from the data of particular article comes just add one column no_of_view or whatever you want to give..
ii) In the starting of page write down the code of php for ::
from the url you can get the id of current article.
then from select query get the value of column no_of_view for particular ID (article)
then fire a query for update that record for no_of_view column with +1
If you want to get that more accurate then add ipaddress column and date also....
I prefer to use Google Analitycs API for such tasks. It' hard to implement for the first time - but once made it will help you on any project.
You can read here - http://code.google.com/intl/en/apis/analytics/docs/gdata/home.html
I would set a cookie on the user's browser and send it to the server. If the cookie is new, it's a new user reading the article for the first time.
I think, you can execute an ajax function, when user click on article to update column in database table field name 'number_of_click' as per article id and other relevant reference
and show it by simple query 'SELECT no_of_click FROM article WHERE id='{$individual_article_id} ....'';
I want to implement user mentions with #username like in Twitter. But, in my app, the username may change. My approach is to parse the post before saving into the database and convert all the #username to #userId. What do you think of this? Does anyone has any better alternative?
Store the original text, as is, and create a table of related records with the uid and username.
Example schema:
post [table]
id
text
user_mention [table]
id
post_id
user_id_mentioned
user_name_mentioned
When a post is saved, your code should go through and create all the user_mention records. You can loop through the mention table to send e-mails or whatever else you want to do.
If the user changes their user name, you now have the option of updating the post with the new username, or having the old username link to the correct user.
My rule is to never, ever modify original unstructured text before saving to the database (but do sanity check it to avoid injections and whatnot) and modify the data only on output. This means you always have the user entered data, and you never know when that will be valuable.
Maybe one day you are interested in who changed their username after being mentioned n number of times? Or some other report that you can't get because you modified unstructured data. You never know when you will want the original data and, in this case, you get the added bonus of having your text easier to work with.
Yeah, I think checking the username list at the post time, and converting them internally to a user ID makes sense. Then, whenever you display the post, translate the user ID back to the current username.
Note that this will be more difficult for non-dynamic content, such as emails sent, etc.
Also, I'd make sure that the usernames are displayed in a way that makes it clear that they're not words the OP posted, otherwise, that would give a way for users to inject text into someone else's post.
Yes I think that is good. Twitter itself doesn't just use Usernames it uses UserIDs.
It gets the tweeters user ID then looks it up to get the the actual username.
Documentation : Mentions and Lookup
Each user should have a unique ID. You should match the ID's with the username before you send it anywhere which would be visible for users.
Whats the best way to keep track of how many users and guests are online? Im making a forum for fun and learning
Right Now I have a 2 fields in the users table called is_online and last_access_time.
If current time is 5 minutes or more than last_access_time i set is_online it to zero. And if the signed in user refreshes browser i set it to 1.
But what about guests? I wanna keep track on how many guests are on also
Another thing that would be really cool is to show what page the user is viewing. and on the page, forum thread for example, 5 guests, Homer and Shomer are viewing this page. But how should i structure this? Hmm maybe i should make another question for that.
i dont know what i should do
What do you suggest?
I'd use cookies for this. Set a cookie when the user enters (checking first to make sure one doesnt exist). Easy way to generate a unique id for that user is to hash their IP plus the current time.
$id = md5($_SERVER['REMOTE_ADDR'] . time());
Store that id in your database and use that to reference
You can check what page they are viewing by grabbing either $_SERVER['PHP_SELF'] or $_SERVER['REQUEST_URI'] near the top of your php source. Store that in the table. I'd take a look at php.net's explanation of whats stored in the _SERVER global, as it should help out quite a bit if you find that you need more then just the document they are on (ex index.php). Found here.
You may need to pull apart of the query string that was used to access that page, parse out the variables to determine the page they are requesting. Either way, this could all be done through cookies, or just use a single cookie to store the unique id and use your table for storing everything else.
You cannot know for certain which page a user is viewing, but you can keep track of which page they last viewed. Every time you deliver a page to a user, record that page's path in a database row associated with them. Voila.
To keep the number of guests, I suggest tracking the number of distinct unauthenticated IP/HTTP-User-Agent combinations seen on a certain page in the last X minutes.
I found this article on Web Monkey that might help you.
http://www.webmonkey.com/2010/02/how_many_users_are_on_your_site_right_now/
Sort of a methods/best practices question here that I am sure has been addressed, yet I can't find a solution based on the vague search terms I enter.
I know starting off the question with "Fast and easy" will probably draw out a few sighs, so my apologies.
Here is the deal.
I have a logged in area where an ADMIN can do a whole host of POST operations to input data relating to their profile. The way I have data structured is pretty distinct and well segmented in most tables as it relates to the ID of the admin.
Now, I have a table where I dump one type of data into and differentiate this data by assigning the ADMIN's unique ID to each record. In other words, all ADMINs have this one type of data writing to this table. I just differentiate by the ADMIN ID with each record.
I was planning on letting the ADMIN remove these records by clicking on a link with a query string - obviously using GET. Obviously, the query structure is in the link so any logged in admin could then exploit the URL and delete a competitor's records.
Is the only way to safely do this through POST or should I pass through the session info that includes password and validate it against the ADMIN ID that is requesting the delete?
This is obviously much more work for me.
As they said in the auto repair biz I used to work in... there are 3 ways to do a job: Fast, Good, and Cheap. You can only have two at a time. Fast and cheap will not be good. Good and cheap will not have fast turnaround. Fast and good will NOT be cheap. haha
I guess that applies here... can never have Fast, Easy and Secure all at once ;)
Thanks in advance...
As a general rule, any operation that alters state (whether its session state, or database state) should use POST. That means the only 'safe' SQL operation you can perform with GET is SELECT. Even if you're only using a back-end admin thing, you shouldn't use get. Imagine re-opening your browser and finding that the last time you closed firefox was on your 'DELETE EVERYTHING' GET->delete page resulting in everything being deleted again.
One of the main reasons for this is preventing cross-site request forgeries. For example, if you had a page that took a GET variable such as http://example.com/account?action=logout, an attacker could post an image on your site like this:
<img src="http://example.com/account?action=logout" />
and anyone who opened a page containing that image tag would be immediately logged out, even if they were an admin. It would be very annoying to then search through your raw database for that data and remove it.
Although POST operations are 'nearly' as easy to forge, as a general rule with any web security issue, the trade-off is speed/simplicity vs. security, so you're going to have to choose one or the other.
You should have some kind of session set up.
Using POST over GET gets you nothing tangible as far as security is concerned. POSTs can be forged just like GETs.
So assuming once your admin logs in, you've got some kind of identifier in the session, you just leverage that.
Consider something roughly similar to this:
<?PHP
session_start();
if (empty ($_SESSION['admin_id'])) die("Log in, son.");
if (empty($_GET['record_id'])) die("You've got to tell me which record to delete!");
if (! is_numeric($_GET['record_id'])) die("Invalid record ID");
//just to be totally safe, even though we just enforced that it's numeric.
$record_id = mysql_real_escape_string($_GET['record_id']));
$sql = "DELETE FROM table WHERE record_id='{$record_id}' AND admin_id = {$_SESSION['admin_id']}";
mysql_query($sql);
echo "Record was deleted (assuming it was yours in the first place)";
?>
In that example, we're avoiding the "delete someone else's records" problem by leveraging the WHERE clause in the DELETE query. Of course, to be more user friendly, you'd want to first fetch the record, then compare the admin_id on the record to the admin_id in $_SESSION, and if they don't match, complain, log something, throw an error, etc.
HTH
You're saying: "What if Admin 123 access the URL of Admin 321 directly, thus deleting his stuff?" no?
If that's so then, every admin that is logged in should have at least one session with some unique identifier to that admin. If not, he shouldn't be able to be in the admin section in the first place. Can't you just compare the identifier in the URL with the identifier in the session?
If any user, not just an admin, access those 'delete me' URLs he should be identified by a session as the original 'owner' (admin) of that data.