I'm developing a service, that uses social graph.
There is a separate module, that manages user connections, that is basically responsible for all related operations. In some services, you need to know all user connections, to provide correct responses.
The way I see it there are 4 possible options to implement this:
Server based connection support.
1.1. Each time social graph data requested ask for friend list from the module, and process corresponding response.
1.2. Have internal cache with Key - playerID, Value - all player connections, add responsibility to update this cache to connection module, and use it instead of referring to this module.
Client based connection support.
2.1. Add a special Cookie with the list of all friends, so that server could just read that Cookie and provide needed information, without talking to the external module. (This can be secured, by for example providing some signature for the Cookie, and optimised by adding some path, for all the connections related data)
2.2. Add a connection management layer in Client, so it would explicitly request all needed information, by providing a list of connections on each request.
As I look at facebook Cookies, there is a fr cookie, which I can speculate used for this kind of functionality.
How facebook solves this?
If you just want to maintain a list of friends for each user you don't need a full social graph. A simple list of friends stored in your database would work fine.
Client-side storage is typically only for caching or session data, you don't want your users losing their friend list because they re-installed their browser or switched computers.
If you do want to implement a full social graph have a look for a graph DB. Neo4J is one I've used and is fairly easy to get started on.
Related
Background:
I have a single page application that pulls data from a REST API. The API is designed such that the only URL necessary is the API root, ie https://example.com/api which provides URLs for other resources so that the client doesn't need to have any knowledge of how they are constructed.
API Design
The API has three main classes of data:
Module: Top level container
Category: A sub-container in a specific module
Resource: An item in a category
SPA Design
The app consuming the API has views for listing modules, viewing a particular module's details, and viewing a particular resource. The way the app works is it keeps all loaded data in a store. This store is persistent until the page is closed/refreshed.
The Problem:
My question is, if the user has navigated to a resource's detail view (example.com/resources/1/) and then they refresh the page, how do I load that particular resource without knowing its URL for the API?
Potential Solutions:
Hardcode URLs
Hardcoding the URLs would be fairly straightforward since I control both the API and the client, but I would really prefer to stick to a self describing API where the client doesn't need to know about the URLs.
Recursive Fetch
I could fetch the data recursively. For example, if the user requests a Resource with a particular ID, I could perform the following steps.
Fetch all the modules.
For each module, fetch its categories
Find the category that contains the requested resource and fetch the requested resource's details.
My concern with this is that I would be making a lot of unnecessary requests. If we have 100 modules but the user is only ever going to view 1 of them, we still make 100 requests to get the categories in each module.
Descriptive URLs
If I nested URLs like example.com/modules/123/categories/456/resources/789/, then I could do 3 simple lookups since I could avoid searching through the received data. The issue with this approach is that the URLs quickly become unwieldy, especially if I also wanted to include a slug for each resource. However, since this approach allows me to avoid hardcoding URLs and avoid making unnecessary network requests, it is currently my preferred option.
Notes:
I control both the client application and the API, so I can make changes in either place.
I am open to redesigning the API if necessary
Any ideas for how to address this issue would by greatly appreciated.
Expanding on my comment in an answer.
I think this is a very common problem and one I've struggled with myself. I don't think Nicholas Shanks's answer truly solves this.
This section in particular I take some issues with:
The user reloading example.com/resources/1/ is simply re-affirming the current application state, and the client does not need to do any API traversal to get back here.
Your client application should know the current URL, but that URL is saved on the client machine (in RAM, or disk cache, or a history file, etc.)
The implication I take from this, is that urls on your application are only valid for the life-time of the history file or disk cache, and cannot be shared with other users.
If that is good enough for your use-case, then this is probably the simplest, but I feel that there's a lot of cases where this is not true. The most obvious one indeed being the ability to share urls from the frontend-application.
To solve this, I would sum the issue up as:
You need to be able to statelessly map a url from a frontend to an API
The simplest, but incorrect way might simply be to map a API url such as:
http://api.example.org/resources/1
Directly to url such as:
http://frontend.example.org/resources/1
The issue I have with this, is that there's an implication that /resource/1 is taken from the frontend url and just added on to the api url. This is not something we're supposed to do, because it means we can't really evolve this api. If the server decides to link to a different server for example, the urls break.
Another option is that you generate uris such as:
http://frontend.example.org/http://api.example.org/resources/1
http://frontend.example.org/?uri=http://api.example.org/resources/1
I personally don't think this is too crazy. It does mean that the frontend needs to be able to load that uri and figure out what 'view' to load for the backend uri.
A third possibility is that you add another api that can:
Generate short strings that the frontend can use as unique ids (http://frontend.example.org/[short-string])
This api would return some document to the frontend that informs what view to load and what the (last known) API uri was.
None of these ideas sound super great to me. I want a better solution to this problem, but these are things I came up with as I was contemplating this.
Super curious if there's better ideas out there!
The current URL that the user is viewing, and the steps it took to get to the current place, are both application state (in the HATEOAS sense).
The user reloading example.com/resources/1/ is simply re-affirming the current application state, and the client does not need to do any API traversal to get back here.
Your client application should know the current URL, but that URL is saved on the client machine (in RAM, or disk cache, or a history file, etc.)
The starting point of the API is (well, can be) compiled-in to your client. Commpiled-in URLs are what couple the client to the server, not URLs that the user has visited during use of the client, including the current URL.
Your question, "For example, if the user requests a Resource with a particular ID", indicates that you have not grasped the decoupling that HATEOAS provides.
The user NEVER asks for a resource with such-and-such an ID. The user can click a link to get a query form, and then the server provides a form that generates requests to /collection/{id}. (In HTML, this is only possible for query strings, not path components, but other hypermedia formats don't have this limitation).
When the user submits the form with the ID number in the field, the client can build the request URL from the data supplied by the server+user.
i know this is a question that has been asked many time. but im still concerned about best practice when trying to develop secure code in meteor.
i know you can prevent the client from being able to access the database with the command:
meteor remove insecure
my code currently adds, retrieves records by using Meteor.methods() so although the client is not able to insert data into a collection, it can use the Meteor.method() function. im concerned about holding the login details in the database because would this not mean that the client can use the Meteor.method() function to add/get/remove data from the database.
the client being able to call the Meteor.methods() function seems to still keep the same risk doesn't it? or have i coded me work wrong?
if it help, here is a run down of what my work is doing:
application loads
client calls to get username and password from database
client sends login details to external server (over https) to initiate socket.io connection.
step 2 is the risk because it seems to allow the client to get the login details. once it has this, it uses the socket.io.js library and the api to my webservice to login. so meteor remove insecure doesnt seem to have secured it because get methods are still available in the Meteor.methods()?
being able to use these functions are quite crucial to retrieving data from the database, is there a way around this? what would be best practice for communicating to the database without exposing private data to the client?
Meteor's insecure package is just a tool provided by MDG to quickly prototype apps. It is not meant to be runned in a production app and some people think is a best practise to remove it all together from the start.
After you remove this package, if you want to interact with the database on the client using mini-mongo you must create the appropiate allow and deny rules on the collection. Here is the link for the Meteor documentation on this topic. The other way to interact with the database, is as you said, using Meteor.methods().
Meteor methods calls don't trigger allow or deny rules, since they are runned on the server. You must hardwire all the security measures you need on the Meteor Call by yourself. So it can be a security problem if you don't take the time to secure the call.
Regarding authenticating your clients I would suggest you take a look at Meteor's Accounts package. For example you can add this two packages for basic username/password authentication:
meteor add accounts-base accounts-passwords
Then you can just use the methods detailed on the Meteor Documentation.
I hope this helps.
Login
If you are using accounts-password, you can check the source here to see details of how it works. But here's a rough overview of it. When you call Meteor.loginWithPassword, the password is hashed client-side. Then a method is called with the parameters. The password is then salted and checked against the database server-side. If it matches, the client gets logged in. The client then subscribes to their own user data (Meteor.user()). The server only publishes their data. So everyone else's data is save.
Methods
A method executes code server-side. So they are generally secure. But you can of course write insecure methods. Just know, that you can't trust the parameters passed by the user.
I have tried Google with queries similar to the title of this question, but haven't found anything useful.
Background: I am building a web app and would like to add a user authentication level to it. I cannot imagine anything worse than building a user authentication system from the ground up, so I want a quick solution.
I'm looking for open source software I can host on my server that provides an auth layer I can connect to, with multiple user accounts
Criteria:
I want to host the software on my own server
Provide a log in screen that works with multiple sign in strategies - twitter, facebook, vanilla email, etc.
Persists users to a database (preferably postgres) and persists session data
Preferably lets me store a minimal amount of data per user, like key value store
Has a client-side (Javascript) API, like Facebook's JS, so I can use this auth service on multiple sites. Namely, I want to use it on localhost or my own file system (when allowing file cookies). Client side JS API exposes methods like log in / log out
Has a server side API (such as exposes local RESTful endpoints) so that when I do build out my server side app for other data storage outside of the user, my app can query the auth service for log in status.
I want to run this stack completely independently of my own app - in fact I want to run this auth service and purely communicate to it from my local dev environment without building any server side app of my own.
I have used Firebase and they do many of the things that I want, including log in strategies and the client / server side APIs, but I want to be able to host my own version of this.
I can't imagine anyone takes pleasure out of building user authentication of any kind, so I'm surprised I haven't found anything in research.
I also know this is an open-ended question, but as far as I can tell I haven't found anything satisfying my requirements.
I like Devise (https://github.com/plataformatec/devise), which is for Rails. It has an active community with a boatloads of plugins available that can fulfill many of your requirements.
I didn't see a language specified; most languages and frameworks have their own implementations. Can you provide more information?
Example: I use the Flask framework on python. In addition, I use the Authomatic library which provides Oauth access for twitter, google, facebook, etc.
What I was looking for is something called a Single Sign On solution. According to this list there is nothing currently that meets my criteria.
Instead I have chosen to just run a local webserver and implement a regular auth flow.
I have been asked to use ember for front end and java rest services as the backend. I am trying to figure out how to manage session for a particular user.
i know there are couple of options like storing in the local store, cookie but they are error prone as some users might disable those features. I want to know what is the preferred approach in normal enterprise apps.
Mine app is simple 15 page app. i need to capture user, and some profile details.
Session are usually more of server side part. You have to just make sure whether the provided session is available or not for every transformed route and request. There is a library which takes care of authentication and authorization in ember https://github.com/simplabs/ember-simple-auth.
We intend to develop rest based api. I explored the topic but it seems, you can secure api when your client is an app (So there are many ways, public key - private key etc). What about websites / mobile website, if we are accessing rest based api in website which do not use any login for accessing contents ( login would be optional ) then how could we restrict other people from accessing rest based api ?
Does it make sense using Oauth2.0 ? I don't have clear idea of that.
More clear question could be ,How can we secure get or post request exposed over web for the website which doesn't use any login ?
If it's simple get request or post request , which will return you json data on specific input, now i have mobile website , who will access those data using get request or post request to fetch data. Well, some else can also access it , problem is i am not using Login, user can access data directly. But how can we restrict other people from accessing that data.
What do you think is the difference between securing a website that is not using REST vs one that is using REST API?
OAuth provides authorisation capabilities for your site, in a REST architecture this means a user of the mobile application will have to provide their credentials before being allowed to access the resource. The application can then decide on if that user has access to the requested resource. However you've said your website doesn't need use authorisation.
You can use certificates however good luck managing the certificate for each client. My take on it is for your explanation you don't need to secure your website because you will never be able to manage a trust relationship between the client and the server. There are some options though:
You build your own client application that you ship out to people which can verify itself with the server using a packaged certificate with the client. E.g. iOS has this kind of feature if you build for that device.
You provide a capability to download a certificate that is 'installed' in the browser and used when communicating to your REST API
Use something like a handshaking protocol so when a client wants to make the first request it says; 'hi I'm a client can we chat?' And the server responds with 'yes for the next X minutes we can however make sure you send me this key everytime you tell me something YYYYYY' (you can use something like SecureUDID or equivalent for other devices than iOS).
There are probably others but you get the basic idea. Again in my opinion if your resource doesn't need authorisation then you don't need to secure that REST API. Can I ask what kind of data are you exposing via this REST API or functionality your providing? That might help provide a better answer.
You want authorization: only some agents (mobile clients) and/or users should be allowed to access those APIs.
To solve that problem, you need identification: a way for the server to tell who is who (or what), so the right decision can be made.
There are many different way to provide some form of identification, depending how much you care about security.
The simplest is a user agent string, specific to your mobile clients. But it can be faked easily. Slightly harder to fake are client based 'secrets' - embed some kind of secret or key in your mobile client code. You can make it really complicated and secret, but as ramsinb pointed out, you can't get security this way as it would require you to be able to guarantee that the secret you're shipping with the client (wether it's code, algorithm or any other fancy construct) can't be compromised or reverse engineered. Not happening when you don't control the client.
From there, 3 choices:
Security isn't really required, don't bother
Security isn't really required, but you still want to limit access to your API to either legit users/agents or people ready to invest some time hacking your protection - go with a specific user agent or a client embedded secret - don't invest much into it as it won't block people who really want access to get it anyway
Security IS required - and then I don't think there is a way around authentication, wether it's login/password, user specific (device specific?) keys, OpenID, etc... No matter what, you'll have to add to the user burden to some extent, although you can limit that burden by allowing authentication to persist (cookies, storage....)