got a Node.js web app (bound to http://my.example.com) and an official app's website (http://example.com) that is on WordPress.
The WordPress site is supposed to handle all the users' administration functions i.e. registration, buying app subscription, affiliate tracking etc.. I use it because it is faster for me now to stick with WordPress rather than develop all this stuff myself. So...
The problem I'm facing now is accessing users' credentials stored in WordPress upon logging in to the app.
My guess is that on getting a login post request from the app, I should fetch the user's data from the WordPress utilizing it's RPC api or query MySQL (don't know what is better yet). If the user exists and the password is correct, the user accesses the app, and if this is a new user, a new record is created in the app's database (MongoDB).
I would like to know are there any better solutions to this problem? I'm concerned about the security of this solution. Is it safe to solve a problem this way? What are the possible pitfalls with it?
Thanks for any reply)
IMHO
I should fetch the user's data from the WordPress utilizing it's RPC api or query MySQL (don't know what is better yet).
MySQL. AFAIK, WP RPC doesn't support addUser (see below)
If the user exists and the password is correct, the user accesses the app, and if this is a new user, a new record is created in the app's database (MongoDB).
Here's the problem, now you have 2 user database. It'll be better if you add that new user to WP database, so the new user coming from the app should already have the account in the blog.
I would like to know are there any better solutions to this problem?
Split up the user database so it stands on its own. Like StackOverflow and StackExchange family.
I'm concerned about the security of this solution. Is it safe to solve a problem this way? What are the possible pitfalls with it?
Yes. Use a secure connection between node and MySQL if they don't sit on the same box or local network. Use different MySQL user for each app with proper access.
Related
I'm looking to completely decouple user management, login, permissions, and user data from my application. The main reason for this, is the application will consist of a WordPress site, native app, and a custom PHP API that all need to allow a user to login.
I don't want to use WP as the user login as I don't want to tie all our user data to WP in case we want to migrate to something else in the future. I've looked at things like Auth0, but it seems like it fairly heavy and costly.
What I'd like to do instead is build a separate service that can be used to store user fields, meta data, permissions, and act as a login service.
Based on those credentials, I can give access to certain sections of WP, unlock content on the Native App, and authenticate for certain access level for our API. Has anyone had any experience with decoupling their user management with a similar scenario?
if you really want to decouple the user-management from your app, you can use specifications like oAuth2.0 or OpenID - they are two different specs, and you should have a look and see what fits you the best.
If you write your code in Java, you can use (for free) Spring Security together with authentication-flows - that will cover all security issues as well as all user management flows like registration, forgot password, change password etc.
although I didn't gone to such length as implementing an Auth0, I created a separate user management (wp users) by leveraging on wordpress rest api and its native js client(backbone js). It's by no means completed, but the functionality is there.
Below is the screenshot:
I'm so confused about how to get authentication between an external, consumer website and a Laravel API right. What I'd like is to have a web app for which users are able to present information from the app to other people, using an external website that consumes the app's API. Here's an example of the basic setup in a bit more detail:
A Laravel 5.3 app that has a protected API endpoint api/status. Only authenticated users should be able to hit api/status, and the status returned is a particular status for the authenticated user.
An external website that consumes the Laravel API on behalf of a user, let's call her Alice. The necessary information is stored in the backend of Alice's website so that it can authenticate with the API on behalf of Alice. (The actual implementation I'm working on will be a WordPress site, and the API consumption will be done by a WordPress plugin that I am implementing; so any info stored will likely be stored in the WordPress database.)
The website has a /status page that displays Alice's status to anyone who browses to the page. (Ie, when the /status page is browsed to, an API call to the app is made on behalf of Alice. The returned status is specific to Alice, and is displayed to the person browsing the page.) People browsing to /status on Alice's website do NOT need to do any sort of authenticating to view the status on the page.
That is very simplified compared to my actual goal, but I hope it serves to keep the extraneous details to a minimum so we can focus on my actual question, which is what method of authentication should I use to achieve this?
One thing I DON'T want:
The person browsing Alice's website should NOT be able to use their browser's inspector to watch the API call and from that create further API calls on Alice's behalf on their own.
I have Passport installed on my Laravel App, but if I'm understanding things correctly I don't want to use the basic Access Token issuing workflow, as that would require the people browsing to Alice's website to authenticate using the Alices's credentials. For the same reason, I don't think I want an Implicit Grant Token.
Using a Password Grant Token would require storing Alice's password for the Laravel app on her website. Is it ok to store passwords like this in a WordPress database? It makes me nervous...
The other option available through Passport is to have Alice create a Personal Access Token and store that in her website backend as the token to use to authenticate. But the Laravel documentation seems to imply that Personal Access Tokens are meant for testing and development purposes, which makes me wary of going this route for a production plugin. Plus, doesn't using a PAT make it possible to do the thing I DON'T want above, since the PAT is simply passed in the request header? Or is that problem mitigated by the fact that the API interaction would be done over SSL?
Do I even need to go through Passport to achieve what I want here? Is there a better way?
I've been reading myself in circles trying to understand what the best practice for this kind of setup is. I'm sorry if this question isn't focused enough, but if anyone has any good advice, or can clarify things for me I would much appreciate it!
We have two websites with different domain names. One of them is a wordpress site. Both websites have their own authentication system.
For the sake of convenience, it was decided to have a single authentication for both website and making use of session cookies. I searched about it and got to know about Single Sign On. Can anybody tell me how to implement SSO when one of the website is a wordpress site(if this makes any difference)? I would highly appreciate if any help comes.
Pretty simple actually. From the non-wordpress site, you just need to make the login form connect to the wordpress database and check the user-provided credentials. Wordpress uses an md5 password hash, so make sure you hash the users password with the md5() function before passing it to the database. Handle the return results as normal.
One note, make sure that your database user has permissions from the connecting host. If both sites are hosted on the same server (and IP), it won't be an issue regardless. If not, you need to make sure the database user either has permissions from the second IP or from everywhere ('user'#'%').
I'd like to be able to use these "best of breed" opensource solutions, with the only requirement of some sort of single-sign-on between the different sites. I don't want my users having to log-in in 3 different places, so I though it could be possible with OpenId.
Has anyone tried something similar?
OpenID will not avoid the problem of having to sign in 3 separate times. It was allow the user to share the same login credentials between the sites, but they will have to actually log in to each of the three systems. If that is not a problem, go with OpenID. If it is, you have two options:
Use an LDAP server to authenticate on all three sites. I think all three software packages have modules/plugins for LDAP (Drupal, Moodle, MediaWiki). Once you have the LDAP server running, the rest should be easy.
Write custom modules/plugins for each platform that authenticate against a single database. Maybe you could use the Drupal database as the primary one, and have MediaWiki and Moodle authenticate with that. So, effectively, the user will only have an account on the Drupal site, but will get access to all three. This is basically the same idea as an LDAP server, but might save you some overhead and complication.
There is also the Moodle Integration module for Drupal that attempts to accomplish the same thing, only without MediaWiki in the mix. I would check that out.
Good luck!
here are three possible solutions: (1) sigle sign-in site, (2) inject login/register forms into all sites using server site includes - SSI and (3) - ajax.
Single sign-in site.
suppose you have site1.domain.com and site2.domain.com and you want to login/register at both simultaneously. Probably the easiest way to do it will be to create another domain e.g. login.domain.com that will do the job. Your login/register application will need access to databases for site1 and site2 and/or their api's. Since login status usually resides in the cookies, your login application will need to set those login cookies to both sites simultaneously (on successful login/registration) and delete on logout.
To set cookies for all sites from login.domain.com - all of the must sit on .domain.com and cookie domain parameter must be .domain.com
If your solution needs both api access (to the other applications) and access to the same database by several applications - you may need to deal with database transactions. This is because new registrations won't be visible on other sites until transaction is committed - so for example - you can not call api from within login code to retrieve cookies before committing the transaction with the new registration.
One important detail. If you already have users separately registered at site1 and/or site2 but not on both your signon site will either have to handle those cases or you'll need to sync registrations manually yourself upon deployment of your new registration system. Manual fix won't be possible when extra user input is required to complete the cross-site registration. This point also becomes important when you add new sites requiring some new user input for the registration.
Finally, carefully choose domain name handling OpenID. To the best of my knowledge it is impossible to transfer openid endorsements across subdomains without users consent - please correct me if I am wrong. You don't want to ask users to re-register just because you decide to rename the sub-domain.
server side include (ssi) method
Another solution is to inject those forms via sever-side includes into all sites. This may be considerably harder and will depend on the type of webserver in use and will work slower.
A pre-requisite here is that all your applications run on the same subdomain - so that openid works for all of them.
I've once built common user registration for MW (php) and cnprog (python/django).
My solution was to display the same exact registration form on the wiki and the forum site, while generating and processing this form with django. I did it this way because wiki and forum "skins" are so different that I did not want to surprise visitors with the dramatic change of site appearance when they go to the registration page. This is complicated and I will not do it again :) and instead would go with single sign-in method.
in order to display django output through mediawiki I've created a wiki extension printing apache "include virtual" call to glue django-generated content with the wiki output. This comes with problems.
Apache include virtual on my installation cannot POST to subrequests and cannot pass cookies from subrequests and cannot pass redirect responses (all http headers will be thrown out) to the upstream user requests.
So I've added "was_posted=true" to mark the posts for django and a secret code to prevent cross-site forgery. To get the cookies out - had them printed with cookie_morsel.output_js() in python. So javascript must run on the client for this to work. Any redirects will have to be done with javascript too. Extra work will still be needed to upload files (like avatar picture).
So single sign-on may be the best solution.
ajax may be a neat way around - just build forms in all of your sites with javascript and submit them via ajax. Will work fast and will not break appearance of your various sites,
but this won't please the folks allergic to javascript.
Actually, the only method that does not require any javascript is single sign-in site.
Posted this because I've spent enough time building this thing for MW and django - an hour of typing did not make a difference :).
Here is the situation. I have a site that only allows one user to be logged in at one time. However, I need a server to scrape this site and put data into the database. However the admin need to be be able to log into this site from time to time.
So what I would like is for the server to proxy the admins login so that the server won't attempt to login while the admin is logged in.
How would I go about doing this?
Thanks
EDIT: Sorry, it totally slipped my mind, the reason I need to come up with such a complicated setup is because I do not have the source for this site, nor does the site allow any sort of extensibility. Basically I plan to add features by proxying the site through a more featured filled version of the page that will allow the user to access features not availilbe for the sites normal interface.
If this is a web application you've built yourself, you should be able to track this pretty easily. You just need code that stores the login state of your users in a global way. Possible ways of doing this would be to utilize the database (if this is database driven) or store it in an Application variable (if this is done in ASP.NET).
Then whatever process you've put in place where the server is "scraping" the site can check to see if anyone is logged in before logging in itself.
However, I must ask -- is this something you've built yourself or are you trying to add functionality to an existing product? The reason I ask is that I can't figure out why you tagged this with "proxy" and not the language it was written in. If you don't have access to the source code, for example, that would change things.