I allow Users that have nothing more than username/email/password.
But if they want to access certain areas, i need more information and present a form to them.
Now i want to validate this form, but whatever data is sent, it is valid since the entity is allowed to only have three basic attributes.
Simply checking for the desired fields needed to access a certain area is fairly easy, but communicating missing fields to the form is more complicated.
I'd have to match the fields to the form elements, add custom error messages and so forth.
Is there a best practive for my Problem?
Read up on Validation Groups — that's what you need.
Related
I'm rewriting an API to be more RESTful, but I'm struggling with a design issue. I'll explain the situation first and then my question.
SITUATION:
I have two sets resources users and items. Each user has a list of item, so the resource path would like something like this:
api/v1/users/{userId}/items
Also each user has an isPrimary property, but only one user can be primary at a time. This means that if I want to get the primary user you'd do something like this:
api/v1/users?isPrimary=true
This should return a single "primary" user.
I have client of my API that wants to get the items of the primary user, but can't make two API calls (one to get the primary user and the second to get the items of the user, using the userId). Instead the client would like to make a single API call.
QUESTION:
How should I got about designing an API that fetches the items of a single user in only one API call when all the client has is the isPrimary query parameter for the user?
MY THOUGHTS:
I think I have a some options:
Option 1) api/v1/users?isPrimary=true will return the list of items along with the user data.
I don't like this one, because I have other API clients that call api/v1/users or api/v1/users?isPrimary=true to only get and parse through user data NOT item data. A user can have thousands of items, so returning those items every time would be taxing on both the client and the service.
Option 2) api/v1/users/items?isPrimary=true
I also don't like this because it's ugly and not really RESTful since there is not {userId} in the path and isPrimary isn't a property of items.
Option 3) api/v1/users?isPrimary=true&isShowingItems=true
This is like the first one, but I use another query parameter to flag whether or not to show the items belonging to the user in the response. The problem is that the query parameter is misleading because there is no isShowingItems property associated with a user.
Any help that you all could provide will be greatly appreciated. Thanks in advance.
There's no real standard solution for this, and all of your solutions are in my mind valid. So my answer will be a bit subjective.
Have you looked at HAL for your API format? HAL has a standard way to embed data from one resources into another (using _embedded) and it sounds like a pretty valid use-case for this.
The server can decide whether to embed the items based on a number of criteria, but one cheap solution might be to just add a query parameter like ?embed=items
Even if you don't use HAL, conceptually you could still copy this behavior similarly. Or maybe you only use _embedded. At least it's re-using an existing idea over building something new.
Aside from that practical solution, there is nothing in un-RESTful about exposing data at multiple endpoints. So if you created a resource like:
/v1/primary-user-with-items
Then this might be ugly and inconsistent with the rest of your API, but not inherently
'not RESTful' (sorry for the double negative).
You could include a List<User.Fieldset> parameter called fieldsets, and then include things if they are specified in fieldsets. This has the benefit that you can reuse the pattern by adding fieldsets onto any object in your API that has fields you might wish to include.
api/v1/users?isPrimary=true&fieldsets=items
I'm adding a search endpoint to a RESTful API. After reading this SO answer, I'd like the endpoint to be designed like:
GET /users?firstName=Otis&hobby=golf,rugby,hunting
That seems like a good idea so far. But the values that I'll be using to perform the search will be provided by the user via a standard HTML input field. I'll guard against malicious injections on the server-side, so that's not my concern. I'm more concerned about the user providing a value that causes the URL to exceed the max URL length of ~2000 characters.
I can do some max-length validation and add some user prompts, etc, but I'm wondering if there's a more standard way to handle this case.
I thought about providing the values in the request body using POST /users, but that endpoint is reserved for new user creation, so that's out.
Any thoughts? Thanks.
I see these possible solutions:
not actually a solution. Go with the query parameter and accept the length constraints
go with the POST solution that shouldn't be designed as you mention. As you point out, if you POST a user to .../users you will create a new user entity. But this is not what you want to do. You want to submit a search ticket to the server that will return a list of results matching your criteria. I'll design something as such
POST .../search/users passing in the body a representation of your search item
distribute the query both server side and client side. Say you have complex criteria to match. Set up a taxonomy of them so that the most strict ones are handled server side. Thus, the server is able to return a manageable list of items you can subsequently filter on the client side. In this approach you can save space in the query string by sending to the server only a subset of the criteria you want to meet in your search.
Lets assume one uses a form to update a doc in a collection.
Generally, upon submit, one would use some type of form validation process to verify the sanity of the fields in the form. Then after the data verifies, lets assume that the data is passed to a meteor method to actually update the collection.
But theoretically, a user could use the javascript console to fabricate a meteor call to the same update method. For reasons of security, in order to validate submissions made via the console, doesn't this imply that the fields must be verified for sanity in methods too?
So, for normal submission cases via the form, this will cause the same fields to be verified twice (once during form validation, and once within the method).
Is there an elegant way to get around the redundant verification, or must all methods have a redundant field verification step?
You should consider using aldeed:collection2 for validating updates to collections. Normally you define your schema in /lib and then updates will be validated both on the client and on the server but you only have to write the code once. If you want to avoid double work then only validate on the server because you can't trust the client. This is not recommended because the cost of client-side validation is borne by your user, not your server. You can create a better UX if you validate the fields as they are entered instead of onSubmit because you will give the user feedback earlier.
My basic validation approach:
Event handler on each form field on change event change(){}. This does things like making the field border green for a valid entry, red X for an invalid one.
Collection2 validates document inserts/updates on client
Methods validate their arguments
Collection2 validates document inserts/updates on server
More reading:
http://0rocketscience.blogspot.com/2015/07/meteor-security-no-2-all-praise-aldeed.html
http://0rocketscience.blogspot.com/2015/12/meteor-security-no-4-extending-match.html
I implement QuickFix client and I parse SecurityDefinition message ('d') with many user-defined fields. The service provider wants me not to validate user-defined fields, as he says that they add new fields from time to time and don't want to make us (clients) dependant of this.
Is there a way to cancel validation of user-defined fields for one specific message only?
Thanks...
Take a look at the Configuring QuickFIX page, in particular the ValidateUserDefinedFields parameter:
ValidateUserDefinedFields: If set to N, user defined fields will not be rejected if they are not defined in the data dictionary, or are present in messages they do not belong to.
This does not turn off validation of one particular message of course. It turns off validation for User Defined Fields in messages where they are not defined in the Data Dictionary. If the SecurityDefinition message is the only one they add fields to without prior notification then setting ValidateUserDefinedFields to N is probably good enough for you because:
In other messages, either you defined User Defined Fields in your Data Dictionary and they are validated, or you haven't and they are not validated. In the latter case because you probably won't use those fields there's no harm.
In SecurityDefinition only the User Defined Fields you put in your Data Dictionary are validated, other UDF's aren't which is what you want.
If there's still a use-case that would prohibit you from using that configuration option, please let me know in the comments section.
I'm trying to set autocomplete/suggestions on my site's search form, using Elastic Search's completion suggester feature.
I have a list of products, which are grouped by categories (on multiple levels). The search feature should be able to suggest category names, which are of more interest to users than direct products.
Several of these categories have the same name but a different parent (e.g. 'milk' under parent category 'dairy products' and 'milk' under category 'baby'). When the user selects a category suggestion, she's redirected to another page, with more specific results than mere search method.
Additional metadata (url to redirect to, parent category id/name) are added in the payload field.
I use the output field to return normalized suggestions for different inputs. As stated in the documentation:
"The result is de-duplicated if several documents have the same output,
i.e. only one is returned as part of the suggest result."
But as explained, my outputs may have the same value, while being different results, as they will link to different pages. It is also possible in the future that different category levels will yield different actions.
I am reluctant to differentiate things by adding the full string (i.e. "milk in dairy products") as the output, because:
1. The parent category is conceptually not the output itself but a related metadata.
2. I intend to have some formatting in the results, this forces me to parse the output string to add HTML tags in it.
So, is it possible to deactivate the de-duplication?
One workaround I'm thinking of if it's not possible is to store a stringified json object in the output, with all the data 'll need, both the one displayed in the search form and the metadata currently in the payload. But Id' rather look into existing configuration before resorting to that.