As the title says, I'm wondering if SAML 2.0 Attribute Statements have a definite size limit? Or does the limit vary from IDP to IDP? Thanks!
As long as the Response is being sent via a POST transaction, or being retrieved via Attribute Query, there's no limit on sizing of the Response and its various Attribute statements. With the Redirect binding (uncommon for Responses for security reasons), the use of large Attributes will be governed by any limits that browsers may impose on size of the supported URL (as an example, I believe IE11 still has an 8K character limit on the length of the URL).
Related
Say we have a rest api which aggregates data about a Person from other services. One of the Aggregator service routes is GET /person/(person id)/driverinfo which tells us whether the person is a licensed driver or not, license id, expiry date of license and the number of traffic violations. These data can be picked up by the Aggregator from one or more other services. This api will be used by a web page to show the "driver info" about a person. It will also be tested with automation.
Currently, the api gives 204 no content response for persons who never had a driving license. This is because one of the underlying apis gives a 204 for that scenario. So, it was decided that the Aggregator should do the same.
But, I believe that this is not a good response. Instead, we should return 200 with appropriate values for the fields. For example, licensed=false, licenseId = N.A. etc. when the underlying api gives a 204. I.e. the Aggregator should generate these fields and their values.
Which approach do you think is better and why ?
204 means something specific in HTTP; it says that the server found a representation of the requested resource, and that representation is zero bytes long.
Therefore, the real question is more like "Should we use a zero byte long message to describe a situation?". Maybe? If all of the fields in your message schema are optional, and we are trying to describe a representation that means that all of the fields are taking on their default values, then a zero byte array might be the right way to communicate that.
Within the context of HTTP specifically, the headers themselves are already significant in length (compared to zero), so I wouldn't expect there to be particularly compelling performance reasons to squeeze a signal down to zero length. For instance, if we were normally passing around application/json, I would expect that sending an empty object or array to be much more cost effective than sending nothing at all.
When designing a HTTP RESTful API is it ok to have parameters with default values when they are omitted? or is that confusing?
for example:
/posts?categories=20,21,18
is missing a limit parameter, so we set the limit to limit=100 by default
/posts?categories=20,21,18&limit=200
sets the limit to 200 overriding the default.
Is it okay to have defaults for params in an API? or will this simply confuse developers trying to understand the API? Should default params responsibility be on the client consuming the API?
While the answer to this question largely depends on the circumstance, providing reasonable defaults is very common.
For example, we can look at how Google does things with their search. When searching for cats you can use their q parameter: https://www.google.com/search?q=cats. Google won't return all 635,000,000 results because you didn't specify a limit, they make a reasonable assumption that they can limit the results to a set number and wait for you to request more.
Looking further into your example, you really only have two options for when the client consuming your API omits the limit param:
Return an error
Set a default
Generally you want to avoid returning errors unless something actually goes wrong (for instance if the endpoint has a required field that is essential to the process).
So we set a default. In the case of the limit param, aside for responding with an error, there is no way to avoid setting a default. Whether you respond with every possible entry, 100 entries, 1 entry, or none, all of those are a type of default. In essence, not choosing is a choice.
Of course it is ok. And it won't confuse devs as long as your documentation is well maintained and shows what parans are required and which one have default values. Have a look at the rest api docs of GitLab for example.
It very ok to specify default if you know that the caller of the endpoint may omit the parameter in the url. This way codes will not be broken.
I need to know the maximum length of
JSON Web Token (JWT)
In specs there are no information about it. Could be that, there are no limitations in length ?
I've also been trying to find this.
I'd say - try and ensure it's below 7kb.
Whilst JWT defines no upper limit in the spec (http://www.rfc-editor.org/rfc/rfc7519.txt) we do have some operational limits.
As a JWT is included in a HTTP header, we've an upper limit (SO: Maximum on http header values) of 8K on the majority of current servers.
As this includes all Request headers < 8kb, with 7kb giving a reasonable amount of room for other headers. The biggest risk to that limit would be cookies (sent in headers and can get large).
As it's encrypted and base64ed there's at least 33% wastage of the original json string, so do check the length of the final encrypted token.
One final point - proxies and other network appliances may apply an abitrary limit along the way...
As you said, there is no maximum length defined in the RFC7519 (https://www.rfc-editor.org/rfc/rfc7519) or other RFCs related to JWS or JWE.
If you use the JSON Serialized format or JSON Flattened Serialized format, there is no limitation and there is no reason to define a limitation.
But if you use the JSON Compact Serialized format (most common format), you have to keep in mind that it should be as short as possible because it is mainly used in a web context. A 4kb JWT is something that you should avoid.
Take care to store only useful claims and header informations.
When using heroku the header will be limited at 8k. Depending of how much data are you using on jwt2 it will be reach. The request, when oversize, will not touch your node instance, heroku router will drop it before your API layer..
When processing an incoming request, a router sets up an 8KB receive
buffer and begins reading the HTTP request line and request headers.
Each of these can be at most 8KB in length, but together can be more
than 8KB in total. Requests containing a request line or header line
longer than 8KB will be dropped by the router without being
dispatched.
See: Heroku Limits
With the following request, it is possible to retrieve multiple Users with the Facebook Graph API:
https://graph.facebook.com?ids=user1, user2, user3,...
Does anyone know if there is a limit for the number of users I can retrieve in a single query?
Depending on how and through which servers you are passing the URL, there could be a limit of 255, 1024 or 2083 characters to the maximum URL length. If one existed, this would be your limiting factor. If you're using javascript to make the query, you should probably assume a max length of 1024 characters or less.
Assume you're passing this via a server-side script with no limits on outbound URL length, I'd guess you'll find there is a Facebook limit. Facebook seems to like 5*10n-item limits their services. I'd suspect this one is probably the same, with n=1, 2, or 3.
I am bolting a REST interface on to an existing application and I'm curious about what the most appropriate solution is to deal with resources that would return an exorbitant amount of data if they were to be retrieved.
The application is an existing timesheet system and one of the resources is a set of a user's "Time Slots".
An example URI for these resources is:
/users/44/timeslots/
I have read a lot of questions that relate to how to provide the filtering for this resource to retrieve a subset and I already have a solution for that.
I want to know how (or if) I should deal with the situation that issuing a GET on the URI above would return megabytes of data from tens or hundreds of thousands of rows and would take a fair amount of server resource to actually respond in the first place.
Is there an HTTP response that is used by convention in these situations?
I found HTTP code 413 which relates to a Request entity that is too large, but not one that would be appropriate for when the Response entity would be too large
Is there an alternative convention for limiting the response or telling the client that this is a silly request?
Should I simply let the server comply with this massive request?
EDIT: To be clear, I have filtering and splitting of the resource implemented and have considered pagination on other large collection resources. I want to respond appropriately to requests which don't make sense (and have obviously been requested by a client constructing a URI).
You are free to design your URIs as you want encoding any concept.
So, depending on your users (humans/machines) you can use that as a split on a conceptual level based on your problem space or domain. As you mentioned you probably have something like this:
/users/44/timeslots/afternoon
/users/44/timeslots/offshift
/users/44/timeslots/hours/1
/users/44/timeslots/hours/1
/users/44/timeslots/UTC1624
Once can also limit by the ideas/concepts as above. You filter more by adding queries /users/44/timeslots?day=weekdays&dow=mon
Making use or concept and filters like this will naturally limit the response size. But you need to try design your API not go get into that situation. If your client misbehaves, give it a 400 Bad Request. If something goes wrong on your server side use a 5XX code.
Make use of one of the tools of REST - hypermedia and links (See also HATEOAS) Link to the next part of your hypermedia, make use of "chunk like concepts" that your domain understands (pages, time-slots). No need to download megabytes which also not good for caching which impacts scalability/speed.
timeslots is a collection resource, why won't you simply enable pagination on that resource
see here: Pagination in a REST web application
calling get on the collection without page information simply returns the first page (with a default page size)
Should I simply let the server comply with this massive request?
I think you shouldn't, but that's up to you to decide, can the server handle big volumes? do you find it a valid usecase?
This may be too weak of an answer but here is how my team has handled it. Large resources like that are Required to have the additional filtering information provided. If the filtering information is not there to keep the size within a specific range then we return an Internal Error (500) with an appropriate message to denote that it was a failure to use the RESTful API properly.
Hope this helps.
You can use a custom Range header - see http://otac0n.com/blog/2012/11/21/range-header-i-choose-you.html
Or you can (as others have suggested) split your resource up into smaller resources at different URLs (representing sections, or pages, or otherwise filtered versions of the original resource).