Let's say that I'm developing an application similar to Twitter. I can see the profile of a user tom if I visit https://twitter.com/tom, but there are several application reserved endpoints like /login, /logout, /settings, /about, etc.
Twitter actually tells you the reason why you cannot take a certain username:
And I suppose the following message applies to reserved endpoints:
My question is: how does Twitter maintain a list of reserved endpoints for filtering out new registrations? It would appear that there is one check that matches the username against a list of registered users, and a second check that looks for reserved keywords.
Keeping a table with these keywords seems like an obvious answer, but I find one could easily forget to update after each creation of a top level (reserved) page.
You're not going to get an answer to how Twitter does it because that would almost certainly require somebody to break an NDA. I would expect it to be a database table, but I have no inside information.
The preferred practice is to not overload a collection endpoint like that. Better would be
/users/tom
/login
/logout
...
Then your URI structure solves the problem for you.
Related
I was trying to find it in docs or anywhere on the web but I did not find.
What I am asking about?
I am building website for multiple users. Frontend is not important, back backend API is being build in Loopback.
Every user will be assigned to some, let's name it GROUP.
Group content will be then exposed on subdomain but it is not important now.
Users will be kind of admins of their group.
I will have plenty of different models, but I will always have to protect user from accessing elements which not belongs to his group.
How should I do it? I think it will be some middleware but I do not know how to do it properly.
Of course, every user and every element have field "group_id".
I am also trying to find a good solution... I did find this npm package that looks worth a try: https://www.npmjs.com/package/loopback-component-access-groups
Here is a short description of what the package is used for:
"This loopback component enables you to add multi-tenant style access controls to a loopback application. It enables you to restrict access to model data based on a user's roles within a specific context."
I'm struggeling with the same problem, and I did not yet find a satisfatory response.
My workaround is explained in this question. I've got my user ID and with this, I retrieve the data I need to restrict the access. Then I alter the query in accordance with fetched data.
In my use case, we have a number of clients who would like to access a (personalised) Kibana dashboard (pre-made in kibana). However, we wouldn't like different clients to see other clients data (for obvious reasons!)
The problem is, kibana "saves" dashboards as a URL (i.e.):
hxxp://myserver:8080/#/dashboard/Dash-1?embed&_g=(refreshInterval:(display:Off,pause:!f,section:0,value:0),time:(from:now-2y,mode:quick,to:now))&_a=(filters:!(),panels:!((col:1,id:UK-Log-Map,row:3,size_x:5,size_y:6,type:visualization),(col:1,id:Total-logs,row:1,size_x:12,size_y:2,type:visualization),(col:6,id:Logs-by-week,row:3,size_x:7,size_y:3,type:visualization),(col:6,id:Log-histogram,row:6,size_x:7,size_y:3,type:visualization)),query:(query_string:(analyze_wildcard:!t,query:'Name:Joe')),title:'Dash')
would represent a dashboard with 4 elements for "Joe" (filtered in the query - last part of URL).
Changing "joe" to any other client (i.e. "dave") would show their data, thus causing a security hole. What would be the best way to secure the data whilst providing the dashboards for each user?
I have full control over most of the tech used for this, so anything can be considered. I.e. libraries, proxies, RESTful services etc. This just needs a way forward!
Another user has tried to achieve this with encrypted URLs (js), but this seems a little hacky to me. There must be a cleaner way?
We have a little discussion in my team how to handle http restriction in our app.
In our app a user can create products. So we have routes like /products and /product/1/show to list and show products of a user. A user can not see products of another user. The app uses a REST endpoint to fetch the data. The API call looks like this /api/product/1/ to fetch a single product.
We have more routes/API endpoint for other kinds of entities.
The question is how to protect a route/API request against other users?
We have two solutions:
use the firewall and voters. The voter gets the current url /product/1/show and checks if given product is owned by the current logged in user.
use a voter without the firewall: http://symfony.com/doc/current/cookbook/security/voters_data_permission.html
use the role system: http://jmsyst.com/bundles/JMSSecurityExtraBundle/master/annotations
I prefer solution 1. because all information we need (who is the owner of the product) still exist. We only need to fetch the entity and do a check.
In solution 2. we have to spread the voter logic over several controllers.
Are there recommendations or experiences on this problem?
If i have to choose between those three it would be 1. But i suggest a different route. I assume that the digit 1 in /product/1/show stands for the user number? If that is the case i suggest that you make new routes without the numbers e.g. /my-products/show . The controller must then use the id of the currently logged in user.
Context: I have never work with Stormpath before and want to fully learn how to do certain stuff. To practice I'm creating my own portfolio, including the CMS.
My question is, how can I restrict the registration of accounts to a handful of specific emails using Google API (only me should be able to add and remove content from my own portfolio).
E.g. Allow ONLY example1#gmail.com and example2#gmail.com to register.
I could do it manually, but I do not want to do that. Steps I would like to follow are:
Specify emails
User tries to access the CMS
User is prompted to login or register
Only if user is in the specified list of emails, user can register using Google's API.
I do understand this is a very general question that involves several fields: Google's API, Stormpath, not to mention Express and Node, but maybe someone else solved this problem and I can see some code. Thanks.
I'm the author of the express-stormpath library which I'm assuming you're using. There's nothing out-of-the-box that does this, so I'd like to point out the best way to do this:
Create a custom registration route, and model it after the built-in stuff here: https://github.com/stormpath/stormpath-express/blob/master/lib/controllers.js#L143
In your custom registration route code, add in some code that checks to see if the email address supplied by the user is a valid one or not.
If not, reject their request.
Now, in the real world you probably wouldn't want to do this sort of thing (it's a lot of extra work, and doesn't buy you much). What you'd probably want to do instead is: completely disable account registration on your website. This way, only YOU can create an account using the Stormpath dashboard on https://stormpath.com, but login still works on your site so that you can log in.
Does that make sense?
So basically, what I'm suggesting is that you disable registration on your site by saying:
app.use(stormpath.init(app, {
enableRegistration: false, // this will disable the registration page / functionality
// ...
}));
Hopefully this helps =)
I have a Spotify app and want to persist basic settings per user between sessions. I see the User object has a username field, so it would be easy to do this using my own backend. My question is, is this allowed, without requiring the user to log in, agree to some TOS, etc? Every app I see that persists any data requires me to log in with Facebook.
Usernames are typically obfuscated out in the Spotify API, so they're not the best thing to use. However, the anonymous ID for the user is the same for a given user/app ID combo across multiple machines, so you could use that instead. This sort of thing is what we designed the anonymous ID for, so you're good to go on the ToS front.
I can't find anything that restricts you from load/storing data from your own servers and I've seen 'you'd have to use your own server' suggested in a number of questions.
Not sure why other apps would involve FB - probably to get more info from the user or promote their product.
You should use the User's URI instead of their username though. I would expect it be more stable than the username and less likely to be little Bobby Tables.