I was just exploring Phorum for my website. I already have a separate log in system associated with the main website, which I was hoping to be able to carry over to Phorum, so people don't have to sign up twice.
I saw the way to hook in a SQL database through include/db/config.php, but there seems to be no good documentation on what's going to be carried in the table I set it to. Will is just be username/password?
Assuming it is, is there a way I can have it so if you signed in on my site, you don't have to re sign in for phorum? Even just a link pointing in the right direction would be outstanding. Thanks!
You could modify your site to use the Phorum database and user registration system. This would be the best way to do it. You could write a small SQL import script for your existing users and then just link to the phorum rego page from your site.
If you are not keen on taking this approach, you'd need to update both user tables (yours and phorums) when data was changed / inserted. Also you'd both need to use the same cookie.
Does that help?
Related
I have a complicate question which I can't find answers from online, or maybe I just don't know the best word to describe it,but hopefully you all and help out little bit, thanks you so much.
I want to create a user account system in php
I know how to store user date when they registra an account in form, but next time when people log in how do you know whether they has an account already or not, other words how do you validate their username and password when they come to your side.
You must store the users data they provide on sign up, using a database such as MySQL or a flat-file system such as this class.
May I suggest you search up tutorials etc. using Google or Bing, if you look hard enough you can find anything on the internet ;)
You can always try this out - PHP Login
Dom.
Ps- check out PHPSquad, Tizag and w3schools they helped me massively when first learning PHP!
It is better if you use SQL database to store the users so you have to create a register page to insert the user data into the SQL database then a login page to read the user data from the database and you can make a profile page with the data you asked to the user on the register form you can do this with ASP and PHP I recomend you PHP cause is easier.
Here is a link that shows how to make a simple user registration system with PHP and MySQL but you have to add some security to your system.
I am helping develop a web application for one of the departments in the company I work for.
I was asked to look into a way to log off every user that might be on the application at once, so that if updates to the Web App are pushed out, people aren't working with an old version of it.
My problem is that as I am not very savvy with PHP, JQuery, AJAX, etc. which is what we're using, I have not known exactly what to look for.
We have a timer script running every couple seconds in the background, so I was thinking that I could add an admin button that updated a field in the database which this script could check every so often, and if the field was set, the logoff script could be executed. But this seems like a hack to work around the issue.
The guy I'm working with suggested I look into custom SESSION handlers.
What do you guys think? Any ideas?
Any help would be appreciated. Even if it's an idea on what to start searching for.
Thanks in advance!
EDIT: I should mention that this is a one-page web app. The user is not following any links or leaving the page.
Make an entry for logged in users in your database of choice, maybe memcached if performance is a criteria.
Use a custom Session save handler which stores the sessions in database or file. When you want to destroy all sessions, you can clear the storage (be it database, or file).
Start from - http://php.net/manual/en/function.session-set-save-handler.php
What I ended up doing was the following:
I added a field into one of out database tables and checked its value every time our browser tick came through (about every minute or so). If the field is set when the tick comes through, their page is refreshed, thus logging them off the application and destroying their session (We destroy the session when someone leaves the page).
The users cannot log back in until that field has been reverted to '0'
The admin account can change that field with the click of a button. Therefore their field in the database remains as a '0'
It might be kind of a hack, but it's what I could come up with even after everyone's help. The only issue is that it takes a bit to log everyone off. Problems of pulling vs pushing I guess.
And yes, an email will be sent out some time before logging everyone off so they don't lose work.
Thank you all for your help!
I have a social website in developmenti n PHP codeignitor and MySQL. I am storing user sessions in the database to handle a multi-server enviornment. Currently there is only 1 database.
1) To handle multiple databases (+ the multi server) how and where will the user session be stored? I assume database wont work in a multi-database env.
2) The session ID given to the user, is it an auto increament from the database or generated from the application logic? I assume it should be a GUID?
3) Along with the session ID I have a user_session table which logs all session related details like login_datetime, logout_Datatime, if user was on web/mobile, etc. So this table has to be written to in 2 stages: When the user logs in and again when the user logsoff. The questions is when the user logsoff what is the logic the system should follow to write the date? Like how will the system know which user_session to write the data to since this PK ID is a database driven autoincreament value and created after the main session ID is created. So at end it will need to query user_session table to find the user_Session ID and then write.
Your comment gave me some clues about the best way to solve this problem for you.
First, if the site is launching soon but not live yet, the best way to solve your problem is: don't worry about this problem yet. Just host everything on one server with one database for the time being. Your idea, no matter how brilliant, will need to solve lots of problems with its first few real users before demand picks up enough to require more hardware.
Second, your image and video servers probably don't need a user's session information. If a user requests a web page with a video, and they have enough access to view the web page, then you can probably just send along the video without further auth checking. This choice will also enable you to use a content delivery network (I personally like RackSpace Cloudfiles, with has a partnership with Akamai) for a much-improved user experience over using your own servers.
Good luck!
I have a classifieds website, where anyone (no need for login currently) can post a classified. It is PHP based.
The procedure for posting is currently like this:
click on "New Classified" --->
fill in a form of all information and hit "View classified before publishing it" --->
the form submits to a "verify classifieds" page, where users verify their inputs --->
If everything is okay in the "verify" page, then the user hits OK and the classified is published.
The above procedure isn't exactly optimized. The first page (new_classified) where the form is, is pretty good, but the second page (verify) uses x number of hidden inputs in another form, used to contain the previous pages form inputs.
Now you know how it works on my site.
The issue today is that alot of companies want to publish their classifieds, and alot of classifieds at the same time. This means they have to fill out the form again and again currently.
I am thinking about creating a login, for companies only, so that their information is automatically inputted into the form, so all they would have to do is fill out the specific classified details like "headline" and "description" etc.
How should I do this in my case? Sessions?
This means I will have to create a new MySql table (I use MySql mainly) and store company-profiles there.
So do you think converting to sessions is alot of work? Worth it? More reliable?
I have never used sessions so I wouldn't know.
As a last note, you should know that I use a picture upload tool on the first page of "new_classified". When a user choses a file to upload, the page is automatically *refreshed*, and then the image is displayed on the same page under section "images uploaded". I hope the session wont interfere with this approach.
Thanks
I think it is worth your while to do logins, and even on a very basic level it will help you to identify who is using your site etc.
This is probably a big debate around developers, what is the best way to do a good login system, whether it's basic or not doesn't matter, I think the concepts still stay the same.
In your case I would suggest session cookies along with a login table consisting of user details. This would help you to verify the user on more than one occasion during his/her visit to the site.
A login is checked against a user entry in a table and then a session cookie is created. This session you can choose to never expire also.
You can then on every step check that the user is the user that is supposed to be logged in and get the companies details by checking the username. This would make for a better query in my opinion.
Sessions aren't a lot of work and it's relatively easy to learn.
http://www.php.net/manual/en/book.session.php
http://www.9lessons.info/2010/02/php-login-script-with-encryption.html is a good example of what you can do with this. Have a look around still. There are a bunch of these great tutorials on the web.
I want to allow users as well as me(the admin) to delete data in mysql.
I used to have remove.php that would get $_GETs from whatever that needed to be deleted such as... remove.php?action=post&posting_id=2. But I learned that anyone can simply abuse it and delete all my data.
So what's the safest way for users and me to delete information without getting all crazy and hard? I am only a beginner :)
I'm not sure if I can use POSTs because there is no forms and the data isn't changing.
Is sessions good? Or would there be too many with postings, user information, comments, etc.
Ex: James wants to delete one of his postings(it is posting_id=5). So he clicks the remove link and that takes him to remove.php?action=post&posting_id=5.
EDIT: Alright, so now I am a little confused. While I can't be 100% secure, how do I do this with $_POSTs?
SOO I should use GETs to get all the data to remove.php, THEN have a confirmation submit button and when users click on it, it put all the data into POSTs and delete from the dbc?
Deleting records is a kind of a scary practice. If you or someone makes a mistake there's no real recourse to resolve the issue. Expunged records are very hard to resurrect.
Instead of deleting records, you could add an "active" bit (e.g. Boolean) column that is toggled off when users "delete" records. Essentially your users would be suspending records by toggling them off and the records would be saved in case mistakes or abuse but appear "deleted" to the user. To make this work with your other queries, just add a where clause of active = 1.
You could then have a utility script that's run at some specific date interval that would clean out deprecated, past dated records. You'd also need some type of timestamp for this type of maintenance.
Just a thought. Take if for what it's worth.
I'll echo gurun8 in preferring to 'mark' records as deleted, instead of actually removing data. And then obviously, you'll need to check that the authenticated user has permission to delete the post.
However, it seems very important to mention that $_GET is not safe even with authentication because of cross-site request forgery.
Imagine if Amazon adding things to your cart based on a GET request. All I'd have to do is put an image on my page with that URL, and everyone who visited that page and logged into Amazon will have products added automatically.
To match your example, I don't like Jame's post, so i put an image on my site like this:
<img src='http://example.com/remove.php?action=post&posting_id=5'>
And I send him a link to my page, and ask him to check it out, hoping that at the time he's logged in to your site. Because, of course, he clicked that little 'keep me logged in' button.
So you are right to be concerned about using GET. If you don't want to litter pages with forms, then confirm the action by POST.
Well you have to start by authenticating the users with a login script.
If you want the simplest solution possible, then I'd suggest protecting the directory in which you have remove.php with a simple .htaccess username and password.
If different users have different rights for deleting database entries, then you probably should create a PHP login script and use PHP session.
Bonk me if I'm stupid, but I searched for quite some time for a simple PHP login tutorial that could be placed on a real site (doesn't use session_register(), uses mysql_real_escape_string(), htmlspecialchars() etc) and I simply couldn't find one!
Probably this one comes the closest, you just have to replace session_register() variables with $_SESSION ones for it to work without register_globals (default in PHP5).