I'm building a Membership site using wordpress and Membership Plugin .
The site is still on my localhost. I did some trial sign ups and it worked perfectly well. But I noticed that, I can use even a fake email address such as xyz#gmail.com or something to sign up and create an account. So that's the problem. I don't know how this will work when I moved the site to my server.
But do you guys think this is a security hole ?
And what can I do for this as a solution ?
Here's what I suggest:
On the registration page, add a field where users need to enter a special code to complete registration and make the code as an image (or at least as something robots cannot process easy). This will prevent robots from constantly signing up to new accounts with bogus information.
Next, perform basic email validation to make sure the format is correct.
Next, strip the email address the user entered and verify the domain part is correct and if it is, have your server automatically send an email to the new account holder asking him/her to return to a special section of the site where he/she enters a special registration code assigned to him/her to complete registration.
Also, to save database space (I'm assuming registration info will be stored in one), ask users to complete registration within a limited time period or they will have to start over. If the time is up then relevant data from the database can be removed. I suggest setting the time period to at least one day.
If you are unable to do this, then you may need to find a better plugin that has the functionality I described.
And whatever you do, play with the website on localhost and make as few modifications on the live server as possible. This means make all changes at once on localhost if you can then upload everything at once to the live server.
Related
First of all, I'd like to preface this post by stating that I know this is a terrible user experience...
I have a client who would like to prevent site visitors from sharing login credentials.
Because this is a corporate marketing site, social login is not an option.
The client claims that there is a site where upon registration, a cookie is dropped onto the user's device and the user is also given a unique password that will only work on that specific device.
Does anyone know how to make this work using Wordpress? (I'd like to avoid using third party plugins)
This sounds like the use of Single Sign On (SSO) or 2 factor Authenticaton (2FA) will be needed. The SSO Wikipidea page references a cookie based solution for TCP/IP networks https://en.wikipedia.org/wiki/Single_sign-on so perhaps that's how this came up from your client.
Once you identify what your options are with that, based on what your client is using for authentication, then set up may be a bit easier. I think a plugin would save you a lot of time, since this is a pretty elaborate task. This one may do the trick https://wordpress.org/plugins/miniorange-saml-20-single-sign-on/
Regardless it's pretty challenging to prevent the sharing of credentials. SSO may be a deterrent if that gives access to something else that user doesn't want to share. 2FA doesn't prevent a user from sharing the pin thats generated too. Perhaps the only real way is to require an IP match on a device with bio-metric authenticaton.
I'd like to start a website that provides users with photos editing/storing experience. The initial idea is that the user has his own account where we store the edited photos and some settings. I'm am a WordPress web developer and when I try to consider how to build such a website in WordPress I don't really understand how to provide such a services without having access to user photos. My idea was to create a custom post type and save it with the user as an author. But as an admin of the website, I will have access to all the created/saved photos and I would like to build it in a way that I don't have it. Is it possible?
I've used previously the app to write a diary that saved the data to my Google Drive and if I understand correctly, it never had access to my files.
So my question is: what are the best practices to build such a resource? Is it normal to have access to all of your user photos if you provide such a platform?
In your case, as you will use WordPress and you are the developer you will always have access to the data of everything.
You will always have a way of knowing which data is from user or which data belongs to another user.
You have two options to do this, but this will take some development work:
1 - You must recreate the way WordPress works where the user is not related to an email and not private data that can relate to the user.
Example: You ask the user to register only that only asks for a hash that can be any word, number, or any other information and a second field would be the password.
With this in the backend you get this two information and do some kind of hash I'll give the example using md5 but do not use it.
After that join these two data and this will be the user.
and to login the user needs to repeat this information and will be within the platform. With this you will be able to maintain the anonymity of the user and will not know who the user is.
In this option you will have for each hash and password a different user :)
But I recommend not using wordpress if you choose this option. You can use a framework like CodeIgniter for example which is super simple.
2 - The second way would be to use the normal wp User, not worrying about who the user is and their information. But one way to keep photo information "anonymous" is to generate a unique hash with each user and have some way of relating the user to it.
Example: When uploading a file to edit it will generate a passkey, you must warn the user that when they want to edit this photo or view they will need to type it into an input. With this you will not know which information is from which user. but it requires extra work for the user
This way you will always have anonymity of user information. I hope I helped you somehow.
I have an existing Wordpress site. The plan is to rebuild the site using the cakePHP framework. Due to time restrictions, I want to replace individual sections of the Wordpress site one at a time. This will mean that both apps will be running side by side for a certain period of time. I need to control access to the cakePHP app using the authorization provided by Wordpress. I'm not sure the best way to go about doing this. I've seen similar questions asked a lot, but I have not yet found a clear solution.
I'm thinking about two approaches:
Plan A:
Configure Cake to look for Wordpress's authorization cookies.
configure Cake to look at Wordpress's database.
Borrow some of Wordpress's authorization logic to teach Cake's Auth component how to authenticate WP users.
Plan B:
set up an authorization API on my Wordpress site.
set up separate auth component in cake.
ping the WP endpoint when a user hits a protected page in the cake app and then manually log in the user. (This would create a second set of auth cookies)
Do either of these sound like the right approach? Is there a better way to do this?
Helpful references: Article about Cake session handling, Cake Auth component documentation, Cake Auth tutorial, brief overview of WP authorization, a more in depth look at wordpress authorization
UPDATE
We've started working on this, and it seems like it will work, but there is a very tricky aspect involving password hashing that warrants its own question. If you're following this thread, you may want to have a look.
I once had a similar situation: Cross framework authentication zend + codeigniter which was few months ago...
Anyways, this is what I will prefer:
set up an authorization API on my Wordpress site.
set up separate auth component in cake.
ping the WP endpoint when a user hits a protected page in the cake app and then manually log in the user. (This would create a second set of auth cookies)
Here, I would suggest a slight change which is do-able.
Make sure, you have a token system of SSO. As in, when person is logged in on Wordpress, set another cookie which will have a token: Token will be username + password (hashed) + secret key, which will be same between Wordpress and CakePHP. On either site, look up for cookie and manually log the user in or just perform a database look up. Hashing is important for that cookie!
However, if the site is using different domains, you might need to re-strategize:
I had different domains once. At the login or unauthorized page, I would ping the other website and bring up their login box. On the other website if the user is logged in, they get post login page and if request URI has sent a token, we perform normal operation and return the authorized token to this (current) domain.
In simple words:
Site A = WordPress & Site B = CakePHP
Site B hits a page where authorization is required then, ping Site A for a login (as it happens when u do Login-with-Facebook sort), which will request via a Token (private key) and REQUEST_URI which will be part of SSO verification table on Site A, if person is already logged in then, Site A will return (via POST) a token, which further will be decrypted via (private key) of Site B and log the user in. Private key of B and A will be same.
Hope this was understandable.
Questions? :)
Answer to your questions in comment:
Ideally, why we use SSO? We use it because of many constraints. For example: You have a database of say... a million row with more than thousand tables, you need to add a module over ur huge app already... so, instead, you will use another database... SSO will return user information, which can further be replicated. For example, when you click on 'Login with Facebook', it returns requested information, like email address, or user's name or even profile picture. Which can further be added to our database... Keeping different databases is strongly recommended :)
To your 2nd and 3rd question: Should both sites reference the same users table in the database? different databases is recommended unless, you are using the same data. Or say changing the software platform.
Should I copy the site-specific user rows into separate user tables for each app? Yes, that should happen automatically. Once you are registered on a main site, nothing happens, things should happen once you are logged in already and then go to site B... Once logged in, user info can always be requested :) That way, new site will have active users ! 2 birds?
Don't complicate (bother) yourself with how what works but, concentrate on how, what is achievable in short period. SSO - Logged in - Restricted page - Look out for log ins - Either login - If already logged in - fetch user info - If user info exists - login via secondary site OR set the new user info . Done!
We developers love flow charts! Don't we? I just created one:
Further answers:
Does the "Fetch User Info" stage mean that we take the user info from the site which is logged in, and create a new user (row) automatically in the other site?
Ideally, you will ask permission from the user before they 'allow' their info to be used but, it varies how your privacy policies are.
In other words, one site handles all the registration/user-creation and the other site just waits for that user to show up and trigger automatic creation. OR at the moment a user registers on the one site, BOTH databases get a user row inserted?
one site handles all the registration/user-creation and the other site just waits for that user to show up and trigger automatic creation. You can have both. Sign up on your website and also a trigger based automatic creation. Depends on your strategy. OR at the moment a user registers on the one site, BOTH databases get a user row inserted? That would be a horrible practice! It will kill the motive of SSO. Motive of SSO is to create an auth family which can be used by users so that they do not have to register every now and then for different websites. update only one database at a time and other when required :)
Questions? :)
I have done this once. I don't have the snippets and/or any references to anything. But thought it might be helpful.
Configure WP and CakePHP both to use same session, you can do this by session id and session name,
When User registers for your website, register them using both WP and CakePHP,
Choose one framework that will handle login view from the front end. I had chosen CakePHP as I was more proficient with it, once the login is successful locate the same user in other framework's DB and authenticate the user using their authentication system.
Hope this helps !!!
Suggestions:
If you are building a closed system, meaning you have to be signed in to access anything useful in the site, then you can use CAS . I know it's used by mainly universities, but for closed systems it works.
( If you need to handle anonymous users the suggestions below might help)
Keep it simple and, similar to Part A of your plan, have a cookie ( visible by both cake and wordpress ) that simply states if a user is logged in. The cookie should be created/checked by both cake and WP. Cake does not need to look at WP's DB. The cookie can have information on how the users in each system are mapped.
Have a central login screen, this is similar to what CAS does. But please build your own. CAS does not handle anonymous users. I am currently creating a central login screen for work. It's simple. The central login screen will handle all authentication and create the cookie visible to both WP and cake. This would mean that the login link for WP and cake will redirect a user to a common page. The link will need to provide a callback URL so that after the user authenticates successfully, he is redirected back to the original service. You will need to decide on a central DB for user authentication.
The cookie approach has following bonus:
It's a lightweight solution and can be wrapped with an on/off switch. In WP, simply wrap the cookie logic with a wp_options value.
You can use WP's and cake's authentication system. no need to work with API's and/or sessions. No need to couple applications by looking at each other's DB.
You can keep roles and permissions native, meaning WP will work with it's own roles and permissions system and your cake application will work with it's system.
Adding a new "service" to your platform is as simple as "create/check for a cookie" then use the system out-of-the-box auth system to log the user in.
Single Sign On is as simple as creating a cookie. Single Sign Off would be deleting the cookie.
I can definitely go into more detail on each suggestion if you're interested.
I want to build a custom asp.net control to put on a webpage that will allow people to see a piece of information from my facebook account that requires auth. For the sake of simplicity let's just say I'd like it to display the last thing that I liked. I don't want the visitor to my site to have to be logged into facebook (nor would they have to be my friend on fb). I want my site to somehow store a token that I have authorized and then it will use this token for the access. I know this can be done initially, but I'm confused what happens when the token expires. Or for that matter if I log out from facebook. Is there some type of token or secret or something that I can request that can be auto-renewed again and again by my website independent of any login state that I have as an fb user? Does this require me creating an fb app and associating the token to it?
I don't have any code at this point, I'm looking for a higher level of guidance on the protocol that should be used here, from there I can hopefully figure out the code from existing samples, docs, etc. This is my first code interaction with facebook so don't assume that I know very much at this point :-)
EDIT: I've been reading everything I can about this topic and I can't seem to find a solution. In the past there was an RSS feed but that appears to be gone now. Then there was also the offline_access permission which is no longer available. This seems like such a simple task but I'm just not able to connect the dots. I have been able to get the initial user token with perms for reading "likes", that's easy. Now I can store that in my website's db and use it to make requests for that data anytime someone loads my page. But eventually the token will expire and I'm not seeing any automatic way to renew it that wouldn't potentially involve user "Larry", who happens to be browsing my website, being asked to supply MY facebook credentials. Basically it seems as though I could never log out from facebook or I'd be risking a broken feed on my website. Is the fb auth model just not set up to allow for thist? To summarize again - a user Bob wants to give his permission to acme.com to always be able to display Bob's most recent like regardless of whether Bob is logged in to fb or not. He would only want to have this stop working if he revoked authorization to the WhatDoesBobLike app which runs on acme.com. Possible?
-JT
You would need an extended access token. It will only last up to 60 days and from then you would need to re-extend.
If it were a page you could extend the user access token then grab the page access token which would never expire.
Read more at
http://developers.facebook.com/roadmap/offline-access-removal/
I'm rewriting a website and going from a home-grown authentication model where users logged in with their account id (numbers) and password, to .NET FormsAuthentication where users will login with a username that they choose (or is available) and a stronger password. There are over 38K existing accounts and I'm trying to decide if the existing users should re-register or if I should write some code to do this on their behalf. I've already ruled out creating the usernames for the users because they won't be able to change their username. Luckily we don't have any users named Brenda Utthead.
If the user re-registers, some may gripe about having to do this step again and it may raise some support calls, but I stay with the standard process that everyone has to do. Or I can allow the user to login with their existing userid and password and then optionally give them a grace period to convert their account. I'm hesitant about the latter because it's special code and a possible threat vector because it bypasses the standard authentication mechanism and allows users to log in using less secure credentials.
This application currently accounts for about 40% of our website traffic and I'm not worried about users not coming back to the website because of the possibility of them having to re-register.
What does everyone think?
If you want your users to come back your best bet is to convert their accounts and send an email explaining the transition.
Do not make them re-register whatever you do.
You'll lose half of your users if you do that.
Give them a service so that they can enter their previous user id and have them provide their email address. Email them at the address provided and have them login with their email address as their new user name.
I am about to do the same thing. I am writing a migration page where the user logs in with his/her existing credentials and behind the scenes, I write out to the asp.net membership tables. Do a check first to make sure they haven't already migrated for all subsequent visits.
Don't make them re-register. A little work on your side is all it takes and you need to keep your customers happy.
After listening to everyone's suggestion, I've decided to modify the login. I look at the username they provide and try to guess that they're an existing user. Then I look them up in the old table and if I find a match take them to a conversion screen. There they can quickly convert their account or skip the whole process and login temporarily. The conversion form has fewer fields to fill out b/c I was able to authenticate them against the old user table so I don't need them to provide as much info.
I'm not thrilled with skipping the conversion but that option is only offered for the first 45 days from go-live.
Either convert them or find a way for both membership models to exist together, and somehow convert each user across at login or something.
Think about how long it took to get the 38k members and ask yourself if those were all wiped out, would those same people go through the hassle of signing up again. If you've got a really strong community you should be ok, the hit would just be a matter of time till you're built up.
The other thing you could do to mitigate the risk would be to send out a email, although spam blockers may filter them you could get to a high percentage of your users and tell them about the new membership stuff. Might get some older people back to the site as well in the process.
The biggest challenge is converting all the data that is associated with the user's accounts. People are going to be really upset if they've built up some sort of reputation that you're going to destroy with a new membership system.
This website is a check your balance type of website. It's not a banking site per se, but it exists as a convenience tool to users. I don't believe it would be realistic for users to cancel their accounts because they are forced to re-register.
I do like some of the ideas I'm reading in the responses though.
I would migrate their information and then on their first login ask them to confirm that their membership info is correct (just to be anal).