I am trying to build simple user authentication system in meteor react js but I am not able to add roles to created user I don't know what is going wrong in my project https://github.com/robertjchow/cv
Thanks in advance.
Searching your repository for Roles. calls reveals, that only your client code is adding users to roles.
Now let's think a minute about the fact that client code can be manipulated.
Do you think that this is still a valid authentication, when clients can add users to roles?
Now going a step further and checking the documentation of the package at: https://github.com/alanning/meteor-roles reveals, that the documentation is adding roles only at the server side, while on the client side it only allows reading via isInRole.
Therefore your next steps should be to create new users only on the server with methods and also add the Roles also only there.
Update: To create new users on your server, you need to add the accounts-password package (but keep the accounts-base package). Otherwise there would be no Accounts.createUser function available.
Further reading: https://docs.meteor.com/api/passwords.html
Related
I am using Meteor 1.10 + mongodb.
I have multiple mobile chat & information applications.
These mobile application are natively developed using Meteor DDP libraries.
But I have same users base for all the apps.
Now I want to create a separate meteor instance on separate individual server to keep the users base centralized.
I need suggestions that how can I acheive this architecture with meteor.
Keeping reactivity and performance in mind.
For a centralized user-base with full reactive functionality you need an Authorization Server which will be used by your apps (= Resource Servers) in order to allow an authenticated/authorized request. This is basically the OAuth2 3-tier workflow.
See:
https://www.rfc-editor.org/rfc/rfc6749
https://www.oauth.com/
Login Service
You will also have to write your own login handler (Meteor.loginWithMyCustomAuthServer) in order to avoid DDP.connect because you would then have to manage two userbases (one for the app itself and one for the Authorization Server) and this will get really messy.
This login handler is then retrieving the user account data after the Oauth2 authorization request has been successful, which will make the Authorization Server's userbase the single point of truth for any of your app that is registered (read on Oauth2 workflow about clientId and secret).
Subcribing to users
The Auth server is the single point of truth where you create, updat or delete your users there and on a successfull login your local app will always get the latest user data synced from this accounts Auth Server (this is how Meteor does it with loginWith<Service> too)
You then subscribe to your users to the app itself without any ddp remote connection. This of course works only if the user data you want to get is actually for online users.
If you want to subscribe for any user (where the data might have not been synced yet) you still need a remote subscription to a publication on the Authorizazion server.
Note, that in order to authenticate users with this remote subscription you need an authenticated DDP request (which is also backed by the packages below).
Implementation
Warning - the following is an implementation by myself. This is due to I have faced the same issue and found no other implementation before mine.
There is a full working Accounts server (but constantly work in progress)
https://github.com/leaonline/leaonline-accounts
it uses an Oauth2 nodejs implementation, which has been wrapped inside a Meteor package:
https://github.com/leaonline/oauth2-server
and the respective login handler has also been created:
https://github.com/leaonline/meteor-accounts-lea
So finally I got a work around. It might not be the perfect way to handle this, but to my knowledge it worked for me so well. But yes I still open for suggestions.
Currently I have 4 connecting applications which are dependent on same users base.
So I decided to build SSO (Centralized Server for managing Users Database)
All 4 connecting applications ping SSO for User-Authentication and getting users related data.
Now those 4 connecting applications are developed using Meteor.
Main challenge here was to make things Reactive/Realtime.
E.g Chat/Messaging, Group Creations, Showing users list & listeners for newly registered users.
So in this scenario users database was on other remote server (SSO), so on connecting application I couldn't just:
Meteor.publish("getUsers")
So on connecting applications I decided to create a Temporary Collection called:
UserReactiveCollection
With following structure:
UserReactiveCollection.{
_id: 1,
userId: '2',
createdAt: new Date()
}
And I published subscription:
Meteor.publish("subscribeNewUserSso", function () {
return UserReactiveCollection.find({});
});
So for updating UserReactiveCollection I exposed Rest Api's on each connecting application respectively.
Those apis receive data from SSO and updates in UserReactiveCollection.
So on SSO side when ever a new user is registered. I ping those Apis (on connecting applications) and send the inserted userId in the payload.
So now those connecting applications receives onDataChanged ping from the subscription and gets userId.
Using that userId the connecting applications pings back to SSO and get user details of that specific userId and prepends to the users list.
Thats how I got it all working so for now I am just marking my answer accepted but as I mentioned above that: "It might not be the perfect way to handle this, but to my knowledge it worked for me so well. But yes I still open for suggestions."
And special thanks to #Jankapunkt for helping me out.
I'm working on a React-Redux web-app which integrates with AWS Cognito for user authentication/data storage and with the Shopify API so users can buy items through our site.
With both SDKs (Cognito, Shopify), I've run into an issue: Their core functionality attaches data behind the scenes to localStorage, requiring both SDKs to be run client-side.
But running this code entirely client-side means that the API tokens which both APIs require are completely insecure, such that someone could just grab them from my bundle and then authenticate/fill a cart/see inventory/whatever from anywhere (right?).
I wrote issues on both repos to point this out. Here's the more recent one, on Shopify. I've looked at similar questions on SO, but nothing I found addresses these custom SDKs/ingrained localStorage usage directly, and I'm starting to wonder if I'm missing/misunderstanding something about client-side security, so I figured I should just ask people who know more about this.
What I'm interested in is whether, abstractly, there's a good way to secure a client-side SDK like this. Some thoughts:
Originally, I tried to proxy all requests through the server, but then the localStorage functionality didn't work, and I had to fake it out post-request and add a whole bunch of code that the SDK is designed to take care of. This proved prohibitively difficult/messy, especially with Cognito.
I'm also considering creating a server-side endpoint that simply returns the credentials and blocks requests from outside the domain. In that case, the creds wouldn't be in the bundle, but wouldn't they be eventually scannable by someone on the site once that request for credentials has been made?
Is the idea that these secret keys don't actually need to be secure, because adding to a Shopify cart or registering a user with an application don't need to be secure actions? I'm just worried that I obviously don't know the full scope of actions that a user could take with these credentials, and it feels like an obvious best practice to keep them secret.
Thanks!
Can't you just put the keys and such in a .env file? This way nobody can see what keys you've got stored in there. You can then access your keys through process.env.YOUR_VAR
For Cognito you could store stuff like user pool id, app client id, identity pool id in a .env file.
NPM package for dotenv can be found here: NPM dotenv
Furthermore, what supersecret stuff are you currently storing that you're worried about? By "API tokens", do you mean the OpenId token which you get after authenticating to Cognito?
I can respond to the Cognito portion for this. Your AWS Secret Key and Access Key are not stored in the client. For your React.js app, you only need the Cognito User Pool Id and the App Client Id in your app. Those are the only keys that are exposed to the user.
I cover this in detail in a comprehensive tutorial here - http://serverless-stack.com/chapters/login-with-aws-cognito.html
I'm newbie to Facebook Graph API and Facebook JavaScript SDK but I'd like to know some things:
Is there any way to put my Access Token in a Open Source application without actually showing it? I'm using GitHub and for security purposes I'd like to make it private.
Can I show my user information without asking the users to Authenticate themselves?
Where in Facebook Developers App can I allow more "scopes" to share publicly? For example, user_photos, user_posts, user_likes, user_status, etc...
These "scopes" that Facebook allows by default are actually the information I'm getting from the user while I'm Authenticating them right?
Just to clarify what I'm trying to do, I want to share things about my Facebook Account through the Facebook Graph API in the gh-pages branch on GitHub, but I don't like the idea of having to authenticate every single user that has access to the page.
I'd like to make my user information public, but don't want to show my access token, because it's Open Source and it can get dangerous eventually.
If you'd like to see my repository and have a better understanding of the project. You can access https://github.com/iszwnc/rye
If I recap:
you don't want to share your app access token (good!),
you don't want your users to authenticate.
Basically, you can't hide your token and let your users query Facebook directly. You need some server-side code on a machine that would be the only one reaching Facebook. Your server would play the role of an interface between Facebook and your users. So you will have to:
do the API calls from a server using server-side code (i.e. Node.js),
save the information you want in a database. This is optional but better to avoid the same information to be retrieved multiple times, thus avoiding your future 100 users to (voluntarily or not) reach your app API limit.
let the users query your server using some client-side code (i.e. AngularJS) in order to retrieve what you and only you know (remember, you own the token).
About Github, don't share your token on it. People can generate their own token if they want to run your app. Here are several suggestions:
Add your token to an environment variable which you can set just before launching the app (don't forget to mention that in your README),
Add your token to a file:
Create a credentials.js file that contains an empty token:
// Please use your own token
var APP_TOKEN = '';
Commit the file to Github,
Have a .gitignore file that contains the credentials.js,
var APP_TOKEN = 'now-you-can-put-your-token-here';
Good luck with your project, it looks exciting :-)
I'm working on a basic personal homepage, consists of a single html document, a .css and jquery*.js file. I want to create a blog-ish look via fetching page content from tweets. The standart widget doesn't fit to the look of the page.
I can fetch public tweets from any account with no authentication crap (it's crap because it public data anyway) via API v1. But with API v1.1, it returns authentication error. It wants me to authenticate to fetch public data. Try to navigate this url. it shows ({"errors":[{"message":"Bad Authentication data","code":215}]});.
My question is is there a way to fetch public tweets via client side js? I don't want to create an app to just fetch public data. I don't wan't to use identi.ca or else, but Twitter pushes me to do.
Upon the comment of Zachary Kinebel to Norguard's answer, I thought, as a comment of Norguard's might be helpful to others, I should put it here:
/search.json?q=from:nerdswguitars === recent tweets by NerdsWGuitars /search.json?q=to:nerdswguitars === recent tweets to NerdsWGuitars /search.json?q=from:nerdswguitars OR to:nerdswguitars === both. /search.json?q=#nerdswguitars === posts involving NerdsWGuitars. /search.json?q=#nerdswithguitars === posts trending "nerdswithguitars". But you MUST make sure that you're properly URL encoding the query. Read more here: https://dev.twitter.com/docs/using-search and if you can't find what it is that you're looking for, out of this, then you need to be a lot more specific
EDIT
In the wonderful world of bad ideas, Twitter is sunsetting this answer, as of May 2013, and will require, at minimum, that you either use one of their widgets, and shoehorn it in, or that you set up an application and do application-level authentication, even for public-timeline GET requests.
If they change their mind, or delay the throwing of the switch, this will at least continue to be here.
Use the Search API:
"http://search.twitter.com/search.json?q=nerdswguitars"
You can use the URL-encoded # or # in front of search terms. You can also use keywords like from or to, and specify limits, et cetera.
You can use Mooch, a small application designed to solve this exact problem. Setting up a new Mooch service is very simple, and utilizes Heroku. The
deployment process requires the Heroku Toolbelt application.
Step 1: Create a Twitter app
Visit https://dev.twitter.com/.
Sign in with a Twitter account.
Create a new application.
Step 2: Get Mooch
Clone the Git repository (git clone git#github.com:eloquent/mooch.git).
Change into the Mooch root directory.
Step 3: Create a Heroku app
Sign in with Heroku Toolbelt (heroku login).
Create a new app with heroku create.
Step 4: Configuration
Mooch authenticates requests to the Twitter API using the application-only
authentication method. This requires the consumer key and secret from the
Twitter application created in step 1.
Example authentication configuration
heroku config:set MOOCH_CONSUMER_KEY=xvz1evFS4wEEPTGEFPHBog
heroku config:set MOOCH_CONSUMER_SECRET=L8qq9PZyRg6ieKGEKhZolGC0vJWLw8iEJ88DRdyOg
Step 5: Deploy
git push heroku master
The new Mooch service should now be ready for use. Check the Heroku
dashboard for the service's location.
For more detailed configuration instructions, a demo application and more, check out the Mooch README on GitHub.
I'm developing a new web site that will be a single paged app with some dialog/modal windows. I want to use backbone for frontend. This will call backend using ajax/websockets
and render the resulting json using templates.
As a backend I'll use nodejs express app, that will return the json needed for client, it'll be some kind of api. This will not use server side views.
Client will use facebook, twitter, etc. for authentication and maybe custom registration form.
Client static resources, such as css, js, and html files will be handled by nginx (CDN later).
Questions that I have now:
How can I determine that a given user has the right to do some action in api(i.e. delete a building, create new building)? This is authorization question, I thought of giving user a role when they login and based on it determine their rights. Will this work?
Similar to the above question, will this role based security be enough to secure the api? Or I need to add something like tokens or request signing?
Is this architecture acceptable or I'm over engineering and complicating it?
Passport is an option for the authentication piece of the puzzle. I'm the developer, so feel free to ask me any questions if you use it.
I thought of giving user a role when they login and based on it determine their rights. Will this work?
Yes this will work. You can check for a certain role on the user after it's been fetched from the server. You can then display different UI elements depending on this role.
Will this role based security be enough to secure the api? Or I need to add something like tokens or request signing?
It wont be enough. Anyone could hop into the console and set something like user.admin = true. In your API you'll need to validate a user token from the request, making sure that the related user has the appropriate permissions.
Is this architecture acceptable or I'm over engineering and complicating it?
At the least you should have an API validation layer. That would make a decent enough start, and wouldn't be over-engineering.
For the authentication part of your question i would use everyauth which is an authentication middleware for connect/express. It supports almost every oauth-social-network-thingie.
For role management you could give node-roles a try. I didn't use it myself but it should help you out, because it checks the role on the server side. Of course that is only useful if your API is implemented in node.js. If that's not the case, you have to "proxy" the API calls over your node.js app.
I hope I could help you! :)