The problem is the following.
Client wants an app, that can be sold to different users via Play Store and AppStore. This app has to have a backend server, but users should be able to see only the data that belongs to their user. This is so far a simple authentication/permission problem, but it gets trickier.
If we had a single backend with User Accounts with permission to manage only data that belongs to them, then whoever sells the app will have to pay for the Firebase account for customers traffic usage too.
So the client wants to sell a pair of app + backend, where backends monthly fees are paid by the customer.
Is there a way to configure something like that in Firebase, and make it easy and friendly enough for the customers to set up their account from the app on first startup?
This format unmanaged user seperator. Firebase has simple authentication. Is is not useful for multicompany. Seperate database or develop custom backend.
It sounds like a fairly standard white-labelled app. I recommend keeping each of the re-sold apps in a separate project, which makes it trivial to then charge each buyer separately for their usage.
Related
I'm just a beginner. I have created a website. Now I want shopify store admins to come and sell on my website. To do that I'm gonna need some way to have store admins provide me their store data like products. Shopify provides a way to do that by creating an app which provides scopes and access token. They can give me access token and I can run some REST apis to get that data.
But I want to simplify this process. I want to create an interface which asks for store admins permission to provide me data and then it automatically integrates. Like you install apps on shopify.
You have a very precise and relatively easy job to do here. You want to create what is called a Sales Channel App for Shopify. With that installed in any merchant store, you would have available to you a JSON representation of just the products they want you to sell on your website. As a bonus, every time you do sell a product of theirs on your website, you have the ability to complete the order with fulfillment aspects and their store. It is all automatic as you wish, and works a peach. Try it! You might end up with a huge success story and a very in-demand App in the Shopify App store.
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 am working with a research group that needs to collect Facebook post data for a group of participants over the course of a few months. The goal is let the participants authorize us to collect this information via facebook, and when they post to Facebook, send that information to a secured server.
After reading the Facebook documentation, I'm mostly just confused about how to provide a mechanism for the user to agree to the terms of collecting his/her data. I'm planning on using webhooks to collect the data, which is independent of the client platform, but do I really need to build separate apps for web, iOS and Android just for the approval process?
I'm planning on using webhooks to collect the data, which is independent of the client platform, but do I really need to build separate apps for web, iOS and Android just for the approval process?
You most likely won't get this approved in review anyway.
Permissions must, for the most part, be used to provide a direct benefit to the in-app user experience; collecting data for analytical measures only is explicitly mentioned as a not allowed use case. Whether the users would agree is not relevant here.
For example, user_posts permission, has "non-visible use of this data such as sentiment analysis or guarding against spam bots" marked with a red "X" for nope.
So the only way of getting your app to request the necessary permission(s) from users, would be to add them as testers to the app via app dashboard/API. Anyone with a role in the app which can be asked for any permission, reviewed or not. Those users would however have to have their accounts verified (mobile/text, credit card) and sign up as a "developer" on the FB platform, before your app could send them requests to become testers.
You'd be flying under the radar with that, so to speak. Facebook offers this "loophole" mainly for the purpose of letting developers test and develop their apps properly, before review. It is also explicitly mentioned in the app development FAQ as a way around the need for review, for specific use cases such as wanting to get your blog posts published to your own FB page automatically. It would not cover what you are trying to do so, but it will likely "work" as long as none of your test users specifically raises a complaint with Facebook ...
Not sure if there is any published limit on the number of test users that can be added to an app, people have asked about that in the past, but AFAIK none is documented or otherwise published by Facebook. If there is one, and it is not completely stopping this approach dead in it's tracks (say, a few hundred per app rather than, five), you could use multiple app ids, if you don't need to relate data between user accounts too much - because the app-scoped user ids will be different per app id, so that could making connections between friends that are in different "app-id test groups" etc. difficult. Or you might have to refer to other, less reliable measures of uniquely identifying them, such as email or profile name.
I am playing around with the idea of creating a website for cryptocurrencies, where a user can sign up on my website, enter his API details for one of the exchange markets that I will support, which allows him to trade on that exchange, but using my “more user friendly” web interface.
My main goal is to create a more user friendly interface than what most exchange websites offer. I am not hooking directly into any cryptocurrencies or wallets, all I do is use the API of existing exchange markets, relay the information to my website, where I have a more user friendly interface.
Since this is a very sensitive subject in regards to security, I am trying to figure out, what the best way would be to store the API details of the users.
In general I don’t like the idea of storing the API details on my database server, nor on my server in general. The thought of having my website hacked and all the API details being exposed is terrifying. Of course each exchange website that supports APIs has their own security built in, such as API sessions with 2FA, IP restrictions, weekly generations of new API secret keys, daily trading limits via API, and not allowing withdrawals of wallets via API. But damage can still be done if those API details get stolen.
I would prefer if there would be a way where I would not need to store the API details on my server at all, but rather have the user save them locally on his PC. That way he is in charge of keeping the API details secure.
This thought brought me then to the idea of creating a desktop app using electron (https://electron.atom.io/). That way I can still create the website the way I want, but it’s wrapped into electron, so it always run locally. Before I pursue this idea, I would like to keep investigating my previous idea of a regular website, as I prefer to have my website cloud based, SaaS, to prevent piracy.
So I wonder, storing API details of a user, without saving them on the server, what other options would I have?
Cookies? Probably not secure.
What about localStorage? https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API
Are there other options or am I too paranoid about this? Is it generally accepted to store sensitive API details on a database server along with the rest of the users details?
I think saving data in to users computers is wrong way, because when you will save user's personal data in to your server, you will be able to control security of your server, when it will be saved on user compputer the security of your server will be depended from users. Today we know many methods how to deceve users and I think, that the programmers must take care of his users. when you will save data in server db you can switch many methods, like email verification or verification by phone you can send message with some verification code, switch ssl service, also you can avoid on sql injection using a modern framework like Laravel or Yii 2, in any case if you will save user data in you server the security of your application will be depended of you.
if you will save user data in local computer, today hackers uses many methods to steal users cookies or methods to get a controll on pc, for example you can read this post
https://krebsonsecurity.com/2011/09/right-to-left-override-aids-email-attacks/
today hackers using this method, creates an exe file which extension on first look is docx or other some extension for example pdf and so on ...
but in real it is an exe file and it is runnable, user can download it, and run... I think you understood what can do hacker with users computers by this way, today so many viruses which even very professional users cant recognize.
Hi I am building a "Twitter clone" for my school project.
I want to implement a publish subscribe pattern for realtime updates.
Users can "follow" other users
When a user is online, and a "follower" posts a new message, the user should get a realtime notification.
I am using Node.js, Socket.io, Redis and MySql as database provider. Should I use a message queue, and whatfor are people using message queue's?
Thanks for help and answers
Update
The problem is not there when you are small. But when you get big the fanout(forwarding message to all followers is going to be expensive and you want to do this offline using a MQ. Like twitter you store all active tweets in memory. When a tweet is posted you put(set) that tweet in memory #key(unique). You could use something like Twitter's snowflake for that.
Next the fanout process happens. For every user you need to put that unique key(tweet id) in their list so that they can retrieve the tweets from memory. When your site is small I guess you could do this without a message queue, but when you need to distribute a message from a user like for example scoble with 274,776 followers and who tweets a lot this can get pretty expensive.
A lot of users are offline so these tweets do not need to get delivered to the user immediately. You design your system like this because you need to keep everything in memory. I think that is the only way to do this effectively.
You should use a MQ just like twitter does. They have even open-sourced their own MQ: Kestrel. The High Scalability blog has a really interesting article: Scaling Twitter: Making Twitter 10000 Percent Faster. I advice you to study at least hot articles at High Scalability blog to learn how the big players scale their website. Some other links explaining how Twitter scales:
http://highscalability.com/blog/2009/10/13/why-are-facebook-digg-and-twitter-so-hard-to-scale.html
http://highscalability.com/blog/2011/12/19/how-twitter-stores-250-million-tweets-a-day-using-mysql.html
http://highscalability.com/blog/2009/4/20/some-things-about-memcached-from-a-twitter-software-develope.html
I also assume you have read:
http://redis.io/topics/twitter-clone
Also I would have a look at all the projects Twitter has open-sourced:
https://github.com/twitter
I would have a look at the popular MQs like for example:
Redis
Beanstalkd
Gearman.
I recently worked on a similar use case, and I used nodejs, socketio and redis pubsub.
The code is available at https://github.com/roshansingh/realtime-notifications.
Now coming back to your questions:
Users can "follow" other users
When a user is online, and a "follower" posts a new message, the user should get a realtime notification.
You can achieve both by creating rooms using socketio and a channel with same name in redis pubsub.
The flow can be something like this:
You can make user join socketio rooms(say John, Dan etc) as soon as they login for which you will save all their subscribed rooms in database. And that the same time you will subscribe to redis pubsub with these channel names (like John). These updates when received can then be broadcasted to the rooms, and hence to all the online users.
You will have to publish John's activities on the same channel name(John) to redis.
Please read the code on the link pasted above. Let me know if you need any help.