Let's suppose an application with a table with pagination.
The table shows indexed items (item1, item2,... itemN).
The pagination result is provided by a REST GET call like /items
The detail of an item is provided by a GET call like /items/1 or /items/N
The question is: Which is the best way to secure accessing a not allowed item.
For instance.
a) user call to /items results in {1 ,2, 3, 4, 5} whichs prints a
table with links to each detailed item.
b) prevent a call to /item/6
Only stateless solution please, Thanks!
Not sure I completely understand your problem. What it seems to me is that you want to have item level authorization. For example, user A should only see items 1, 3 and 5, while user B should see items 1, 2, 3 and 6. If that is the case, you should enforce the authorization constraints for both the list and for the individual items.
If what you want is that a user can only access items he has listed before, you are not in a stateless context. The result of the call to the item is dependent on the previous call. So you have a state. You can move the state around, move it to the client, but it will still be state.
If what you want is the second option and you want your service to remain mostly stateless, have a look into capability base security. Basically, your list needs to return a cryptographic token that needs to be used by the client in order to access the individual items.
Basically, instead of returning just the items IDs, add a cryptographic token with it:
[
{ id = 1, token = 'XXX'},
{ id = 2, token = 'YYY'}
]
The token will be composed of :
a nonce
en expiry date
the item ID to be authorized
a cryptographic signature of the above elements
You sign the authorization token with your server private key, so nobody can forge it. You ask the client to add this token to any request (as an HTTP header). So the server can validate that the client has received an authorization.
You can add the username to the token to make sure the authorization cannot be reused by someone else.
Note that I just describe this implementation from memory. As always with security, please double check anything I tell you ;-)
Related
I have a problem modeling my data in DynamoDB. My APP creates notes with the possibility to share a note with other user and allow the other user to update the Note (as done by https://keep.google.com/).
As I need to share notes between users, I decide that my primary table key will be the identifier of a Note.
Then I come with the following data-model for my DynamoDB tables:
Primary Table :(PK = NoteId, SK = Type)
Secondary Table: (GSK = userId, SK = noteId )
The "Type" will indicate if it is the BODY of the note (where information regarding the note will be save) or an identifier that indicate if the note has been shared with other user.
But I do have a problem: I use the secondary global key to retrieve all the notes for a user.
Once I have the list of noteId(s), I will enquiry my primary table to get all shared-notes for the user (as the notes for the user are already present in the SGK).
However, for doing this I need to use the function: "BatchGetItem".
The problem is that it is only allow to get 100 items and 16MB data.
In case of more than 100 shared-notes I have to call this functions several times. Moreover in case the data exceeds 16MB I need to implement a mechanism to read the rest of the requested data.
This operation could get really slow depending on the data size and number of shareId.
As you can imagine this is easily solved using a RDB and "join".
But the idea here is to use DynamoDB.
Data Access patterns:
Get all Notes by userId (own and shared)
Add a shared by userId and sharedId.
Get rights by noteId and userId.
Update a note by Id
Delete a note by Id
Any ideas of how I can change my data-model to improve the access pattern to read all notes?
Modelling your schema to utilise item collections will allow you to use the Query API which does not have a limit of items returned except a 1MB limit that still needs to be paged through.
I have an initial intent used to classify the user ie Intent1 "I Need help" with a 1 slot (Slot 1) asking "what type of user are you? " The options are "userType1", "UserType2" and UserType3".
following this, with Amazon connect I have a a GetUserInput with multiple inputs. i.e. "What do you need help with?", with lots of intents new intents e.g Intent 2 "Shoes", Intent 3 "socks" Intent 4 "sandals.
Within Intent 2, I want to give a specific text response, Based on the answer to Slot1. the intents are different?
You have to manage context of the conversation to be able to take actions based on previous responses.
https://docs.aws.amazon.com/lex/latest/dg/context-mgmt.html
Basically in the first intent, based on the slot value you have to store it in session attributes, in the next intent you will check the value and generate the response.
Do check the OrderFlowers Blueprint Lambda function and this link. Notice that once the user gives the slot value of FlowerType it sets the price as session attribute.
Hope it helps, let me know if you have further doubts
I wanted to fetch the List of Entities from database at Front end.
So I have written POST REST HTTP call in Spring MVC.
But I read the HTTP documentation which says whenever you have to retrieve data from database prefer GET call.
So, Is it there is any I can replace the POST call to GET call from angular JS and pass list of Integers.
But, GET HTTP has many drawbacks like : the length of URL is limited.Considering the case where we have to fetch 1000 entities from database.
Please suggest me the possible way to get the entities or write GET REST API in Spring MVC for list of integers(refers to ID's of Entities).
For Example : Consider there are 100 books in book table, But I want only few books, say id : 5,65,42,10,53,87,34,23.
Thats why I am passing this List of Id's in a List of Integer in POST call.
Currently stuck how to convert this to GET call. In Short, how to pass List of Integers through GET REST call.
I prefer a variant through HTTP path variable for your problem, because of in REST ideology a resource ID is passed after a resource name 'http://../resource/id' and HTTP parameters are used for filtering.
Through HTTP parameters
If you need to pass your ids through HTTP parameters, see an axample below:
Here is your Spring MVC controller method:
#RequestMapping(value = "/books", params = "ids", method = RequestMethod.GET)
#ResponseBody
Object getBooksById_params(#RequestParam List<Integer> ids) {
return "ids=" + ids.toString();
}
And you can make a call using next variants:
http://server:port/ctx/books?ids=5,65,42
http://server:port/ctx/books?ids=5&ids=65&ids=42
Also take a look this discussion: https://stackoverflow.com/a/9547490/1881761
Through HTTP path variables
Also you can pass your ids through path variable, see an example below:
#RequestMapping(value = "/books/{ids}", method = RequestMethod.GET)
#ResponseBody
Object getBooksById_pathVariable(#PathVariable List<Integer> ids) {
return "ids=" + ids.toString();
}
And your call will be look like this: http://server:port/ctx/books/5,65,42
Pros of GET HTTP call : It is always used for retrieval of Data.(From this perspective : we should implemented for each and every and retrieval)
Through HTTP parameters
If you need to pass your ids through HTTP parameters, see an axample below:
Here is your Spring MVC controller method:
#RequestMapping(value = "/book", params = "ids", method = RequestMethod.GET)
#ResponseBody
Object getBooksById_params(#RequestParam List<Integer> ids) {
return "ids=" + ids.toString();
}
It works fine but for exceptional case : say URI is above 2048 characters. It means there are many Id's in the list(eg : 1000)
then its throws an exception :
return 414 (Request-URI Too Long)
which is http://www.checkupdown.com/status/E414.html
After some research MY UNDERSTANDING is : The HTTP protocol does not place any a priori limit on the lenght of a URI. Servers MUST be able to handle the URI of any resources they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414(Request_URI Too Long) status if a URI is longer than the server can handle.
I have also gone through sites like to get the GET URI length :
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.1
So conclusion, is stick to POST call when there can be variable URI length at runtime for not getting such exception[return 414 (Request-URI Too Long)]
Alternatively, to allow for complex queries you'll need to give the query its own rest language. So to create a query you POST to /library/query then you edit it with things like POST /library/query/12345 with data {id:34} and then you execute the query with GET /library/books?query=12345
Simply you can call list like this:
***/users?id=1&id=2
If you want to read entities from your API you have to use a GET call.
The better way to get them all is to use a query params as filter.
REST DESIGN cannot retrieve more than one entity each time by id.
An example:
GET /library/books/58731 -> returns only one book identified by 58731
GET /library/books?numPages>70 returns all the books with more than 70 pages
I think that If you need to retrieve a lot of books because they have some logic that all matches, try to put it as a queryString.
Another example:
GET /library/books?stored>20150101 returns all the books added to library on 2015
If you give us more information about the collection and the requirements we will answer more directly.
I'm considering an app which will store customer data. Given the way buckets work in CouchBase, all customer data will be in one bucket. It appears that I have two choices:
Implement multi-tenancy in views, by assigning a field to each record that indicates the customer it belongs to.
Implement it by putting a factor on every key that is a customer ID.
It seems, though, that since I will be using views, I'll really want to do both. In case number 2, I need to have the data in the record so that it can be indexed on (or maybe I can pull out part of the key in the map phase and index on customer) and in option 1, I'd want it to be part of the key as a check when retrieving data to make sure I don't send the wrong customers data down the line.
The problem is, this is a service where multiple customers will interact, and sometimes one customer will create some data and the other will view it, at the first customers request. But putting an ACL on each record that lists everyone who's authorized to view it would be problematic, to say the least.
I bet there is a common methodology or design pattern to answer this question, and would appreciate some pointers to best practices.
I'm also concerned about the performance if the indexes are indexing both on the particular piece of relevant data, and the customer id... a large number of different customers would presumably make the indexes much less efficient. (but maybe not.)
Here are my thoughts on your questions:
[Concerning items #1 and 2] - It seems, though, that since I will be using views, I'll really want to do both.
This doesn't seem to make sense to me. In Couchbase, the map phase can include content from both the key and the value. It makes little sense to store the data in both the key and the value, as you are guaranteed to have 1:1 duplication there. Store it wherever it makes the most sense to store it; in this case, probably the value.
The problem is, this is a service where multiple customers will interact, and sometimes one customer will create some data and the other will view it, at the first customers request. But putting an ACL on each record that lists everyone who's authorized to view it would be problematic, to say the least.
My site also has muti-tenant data stored in a single database. In my case, I use object unique identifiers as my keys. By default, customers can access all objects that belong to them (I have a user object, and the user is associated with a customer account). Users may also have additional permissions assigned to them, whereby a single object from another customer could be added to their user account, and they would thereby be granted access to view the object.
The alternative is "security through obscurity" and use guids as a random identifier, giving customers access to view any object that they have the guid for.
I would not, however, try to store the permissions on the objects themselves. That would quickly become unwieldy. You need to think about your specific use case, and decide what simple approach would work for the majority of the cases, and just not support the other 1-2% of the cases.
I currently have a .NET method that looks like this - GetUsers(Filter filter) and this is invoked from the client by sending a SOAP request. As you can probably guess, it takes a bunch of filters and returns a list of users that match those filters. The filters aren't too complicated, they're basically just a set of from date, to date, age, sex etc. and the set of filters I have at any point is static.
I was wondering what the RESTful way of doing this was. I'm guessing I'll have a Users resource. Will it be something like GET /Users?fromDate=11-1-2011&toDate=11-2-2011&age=&sex=M ? Is there a way to pass it a Filter without having to convert it into individual attributes?
I'm consuming this service from a mobile client, so I think the overhead of an extra request that actually creates a filter: POST filters is bad UX. Even if we do this, what does POST filters even mean? Is that supposed to create a filter record in the database? How would the server keep track of the filter that was just created if my sequence of requests is as follows?
POST /filters -- returns a filter
{
"from-date" : "11-1-2011",
"to-date" : "11-2-2011",
"age" : "",
"sex" : "M"
}
GET /Users?filter=filter_id
Apologies if the request came off as being a little confused. I am.
Thanks,
Teja
We are doing it just like you had it
GET /Users?fromDate=11-1-2011&toDate=11-2-2011&age=&sex=M
We have 9 querystring values.
I don't see any problem with that
The way I handle it is I do a POST with the body containing the parameters and then I return a redirect to a GET. What the GET URL looks like is completely up to the server. If you want to convert the filter into separate query params you can, or if you want to persist a filter and then add a query param that points to the saved filter that's ok too. The advantage is that you can change your mind at any time and the client doesn't care.
Also, because you are doing a GET you can take advantage of caching which should more than make up for doing the extra retquest.