I am starting a website and activated WP-Members for my user registration/login. This is great because I can then easily capture user_id in the MySQL table for writing my queries. But I am thinking I probably should also offer Facebook login or maybe even the Social Connect plugin as well.
The problem I'm guessing is that facebook login or any such social media login will use a different variable for user_id (such as fb_login) and so users who login this way will not be placed in the same Members table as users who login with WP-Members. Therefore, I'm not sure the easiest way to go about offering both registration methods.
Is it just too complex to do in general for a newbie to make both registration options establish users in the same table or at least make it easy for me to reference user_id for both methods when trying to run user-id conditional statements and such?
The problem I'm guessing is that facebook login or any such social
media login will use a different variable for user_id (such as
fb_login) and so users who login this way will not be placed in the
same Members table as users who login with WP-Members.
Unless a membership plugin creates and uses its own user table, all users are saved in the same table in WordPress - wp_users. Altering that would severely restrict your ability to integrate with other plugins and/or WordPress itself since you'd be trying to manage two separate user tables.
That isn't really the problem you're facing, but I wanted to mention it because in order to address your issue, your mindset has to understand the db schema you are working with.
WP-Members uses the WP db schema so that it will maintain compatibility not only with WordPress, but also with other plugins. There is not need to separate login/registration using a separate table (in fact, I'd advise against that). There are WP-Members users who use Social Connect just fine. They can be integrated because they rely on the same database.
Related
I was looking into how to add a create user account/login to my website, so I could have members join and come back, etc and ended up finding out in order to do that, I'd need to create a new database in my SQL, to store the users credentials, I dont have the option to create any new databases by my webhost. Only the one database is what I can use. Could I just add this to my existing database? Do I really need more than 1 database on SQL for my website? If so, could I add another SQL server direct on my computer and use both, Mine and the web host one where I'm creating the site to manage my website? Im sorry for the few questions, Im really new to all this and so confused and overwhelmed.
You can create multiple tables in same database.just make a table with fields such as user id,password etc. and use it for saving,fetching user details using sql queries.
Could I just add this to my existing database?
Yes, you can tables to the existing database.
Do I really need more than 1 database on SQL for my website?
There are a lot of websites that use just one database. Some websites use connections to multiple databases. What information is stored in which database is frequently the result of factors other than the website. The ability to connect to multiple databases means that a website could use authentication/authorization info from one database, store user profiles and submissions in another, and read information from other sources (for example, historical stock prices, stored in another database.
All of that information could be stored in a single database. Having them as separate databases means that the databases can be managed separately (frequencye of backups, replication to DR site) and makes it easier to share the database across multiple applications. (For example, we would probably want employee payroll and health care information stored in a separate database, with separate access controls.
Could I add another SQL server direct on my computer and use both, Mine and the web host one where I'm creating the site to manage my website?
It may be technically possible to do that, but that's not the way you want to go. That would add another dependency... the website at the web hosting provider would be dependent on having access to another database, which is not being backed up and managed along with your website.
I have several different web applications with their own separate databases. All of these different web applications also use a common database for authentication which contains the list of all of my users and the user's name. To keep things simple, let just say my application databases are like a forum and they track user posts; in the tables they will store a userID and some post text.
Now the problem I am having is that some of my team members feel that what we are doing is messy and frictional because it kind of a pain how to get my applications to display a users name next to their posts which is a very common task. First I have to go to the application database and do something like SELECT userID, postText FROM tblPosts then I have to take that userID and go to the user database and get the actual name with SELECT name FROM tblUsers WHERE userID = X. And then merge data from those two queries together to get it out on the page.
I personally don't mind the way we are doing it as I think it's important to just use a single separate user database for data constancy, but some of my team members want to copy over all of the user names into the local application databases and store the user name next to the userID when recording posts so its super simple to get that information back out. In the event a user wants to change their name (a very infrequent event and we only have about 100 users) we should just run an update in the common database as well as all of the application databases.
This seems like a common issue people might have. Can someone please weigh in on the common approaches to dealing with the problem and what we might want to do.
You have a system with a working single-signon scheme (centralized user identity and authentication). That's a huge competitive advantage.
You've built it simply and cleanly. That's even more huge. This kind of thing is very hard to get right, and you have done that.
(If you were to try to build this with some system like LDAP or Active Directory, you'd have a lot of complex code to maintain.)
Don't let your fellow developers sacrifice that advantage for their personal convenience. If you have to synchronize changes to the user database, you will have problems when things get out of sync. It's a when question, not an if question.
By the way, if your user database and website specific databases are on the same MySQL server, you can do stuff like this to integrate the use of the two different databases. That may meet the needs of your developers.
SELECT u.username, d.opname
FROM userdatabase.users u
JOIN website.transaction d ON u.userid = d.userid
But if you do this, you'll make it hard to migrate your various website databases to other server machines in the future.
I am rolling my own blogging system and I am wondering how to determine permissions and implement them in a blogging system?
What should be the permissions for a commenter, a blogger and an admin?
What is the best way to implement them?
You didn't mention what language/framework you're using. Django includes a very useful and complete set of permissions that you can get up and running with. I'd assume that there are a number of other web frameworks that do the same.
Therefore, my advice is to find a web framework that you like and think is fun (this sounds like a personal project after all) that will handle these kinds of things for you.
I'd go with a combination of a decoupled authentication component, that you can ask if the current user has the role X, and if so allow them to do the thing. That way you can leave the specifics of groups and expiry etcetera to the authentication component.
You could combine this with some specialized authentication for your blogging engine, eg. having a list of posters in the blog object, and always allowing those persons to make posts.
Give each user a "privilege" value and store it in the users table in the database.
for example:
0: plain user (can comment)
1: writer (can write new posts and modify his own posts)
2: moderator (accepts/deletes comments)
4: admin (access to all)
Use a combination of serverside sessions and cookies for logins.
For "advanced" user privileges, use bitmasks and create groups.
Bitmasking: for example, using previous values, user level 3 (2+1) would have both writer and moderator privileges.
I'm trying to build a website that provides a login for users. Once these users login, they will be able to perform functions that will likely query a database. At some point I will need to add/modify/delete contents in the database and I'm wondering how I would be able create a page on the website that I'd only have access to. Ideally I wouldn't like to have a page on my website that allows me to edit information in my database because it could be susceptible to attacks. So how would the experts from stackoverflow create a page to edit information in their database?
get db management software like phpMyAdmin
with login abilities (or utilize the authentication by HTTP server)
Well, create a normal page - but put access restrictions on so that you're only allowed to use it if the logged in account is an administrator. (You define the administrator roles, and make sure you are one.)
You might also want to make sure the page is only served to some known IP addresses - although that becomes a pain when you suddenly want to use it from elsewhere...
I'm currently at the very early design stage of building a web app that will be used by companies. Each company will have many departments and each department many staff. Each department will manage its own application with staff logging onto the application.
There is the possibility that staff across different organisations will have the same staff id. For that reason, I'm thinking of going with subdomains. Each company will have its own subdomain. I've googled a bit about using subdomains and have seen a number of positives, however not too many negatives except for the SEO implications (which do not interest me really.. this app will require direct contact with each organisation.. it's very specialised)
Can anybody think of any other disadvantages to going with subdomains? Can anyone think of a better way of doing things?
Regards,
Fiona
Your login information will presumably be in a database table somewhere. You will either need separate databases for each company and will need to identify which database to use. Or you will have all users in one table, with some sort of company id - and you will need to determine which company id to add to your login query.
You can make either of these determinations based on subdomain, or on a company-specific login page, or directory, or you can ask them to pick which company they want to log in to (which would be pretty ugly).
Subdomains should work fine. You'll have to do DNS setup every time you add a company, or work out some apache magic. You may need SSL certificates for each subdomain (I think - I'm not well versed on those). Other than that, I don't see any big disadvantages or advantages as far as code or architecture go. Marketing may have a stronger case for one over the other.
You'll still want to use other methods of making sure that users don't have access to other companies' data, especially if other subdomains are guessable.
We also have a multiple-company application, but decided to make all logins unique. This makes it a little easier for us to identify users uniquely at the expense of occasionally having to explain why some username is not available even though that user's company isn't using it.
using sub domains is a good idea, the only concern i have is regarding the authentication of the users. I am a .net guy so i am bringing up this query, i am not sure if you are using asp.net for your development. In case you are using asp.net for developing this website and you are using the asp.net membership, profiles and roles for authentication and authorization, you would end up having security problems. Because a user after logging into http://abc.site.com would have access to the site http://xyz.site.com also. This is the default way the asp.net membership thing works. So you would need to keep this in mind.
Rest i think the sub domain philosophy is good enough.
Subdomains might work just fine with asp.net membership. Because the was the tables are created for the membership provider there is a aspnet_applications table which has fields for te application name and description. In the aspnet_memberhip table, each user has a field for applicationID. If the application name is the subdomain then you could possibly limit which user can gain access to which application. XYZ subdomian would be one application with it's own ID, and ABC application would be another one.
Interesting domain problem. Good luck and share your results after it's creation.