I started playing around with JHipster and created my first JDL-Entities. I learned that an Entity can be "readonly", but is there a way to secure a field like "creationDate" is not changed by anyone?
I added a [readonly]="true" to the input-tag in edit-view, but I want to secure the api behind as well.
There are any suggestions or best practices to do it a clean way?
You could use a DTO so that you select which fields of your entity you want to expose in service layer.
https://www.jhipster.tech/using-dtos/
JHipster uses MapStruct to generate DTOs but you can also do it manually.
Related
I am learning jHipster. My entity relationship model has projects and files. A project can have zero to many files, and a file always belongs to exactly one project.
project <(1:1)-----(0:*)> file
Users interact with the application similar to using an IDE. First, after opening the initial website they always have to select which project they want to work in. (Of course they can also create new projects, or perhaps delete an old one.) Only then they get access to all resources added to a particular project such as files.
As a consequence, my REST API should logically look like this (to get a single file):
GET /projects/{:projectId}/files/{:fileId}
In the backend, depending on whether fileId is a UUID or not, I might even have a method:
findFileByIdAndProjectId(String fileId, String projectId)
The problem is that jHipster creates all entities in a "flat way". Each entity seems to have its own REST API without nesting, and there is simply a reference to an other entity rather than proper composition. Adapting the generated code is quite a bit of work as it requires lots of changes both on the frontend and the backend, but more importantly, it probably breaks the ability to re-create my code when an entity has changed.
I am curious: What different options do I have, and which one would you guys recommend?
Custom code is the way to go though there are few tricks that can help you:
Using DTOs so you can aggregate entities in service layer
Extending generated classes both in backend and frontend so that you don't change generated code, see excellent talk, slides and code samples from Antonio Goncalves
Does NestJS has built-in tools for CRUD generation like Loopback or Sails.js has? I really like the idea of NestJS but i don't want to repeat the same things in each Controller. I will be appreciative if someone could explain how can i reach it?
No, NestJS doesn't have this feature out of the box but you can use nestjsx/crud, It allows you to use all CRUD operation only by declaring an entity class. Check the getting-started page.
EDIT: now NestJS has a built in schematics, you can find a guide here on the trilon blog
I am trying to add a method available for all controllers in sailsjs, much like the blueprint methods are.
The method should also be exposed to a REST route (like /modelName/myBlueprintMethod).
How can I go about and do this?
I have seen lots of Qs for how to override the blueprint methods but what i need is extend the blueprint.
A little context.
What I want to achieve is to expose the schema of the model related to the controller to automate some front-end CMS.
Thanks
I also wanted a similar solution, although it would be a subset of your question: Asked a question here.
One way to go about this (and there could be others) is:
Make a service, send it the parameters and use it in all controllers.
Hope this helps.
I did mine as described here: OVERRIDE CRUD BLUEPRINTS.
I created the blueprint hooks in /api/blueprints/...
We have been looking closely at SPAs using Breezejs for providing the data context between the client and the server. The features look great on the client, but we want to use the Repository pattern on the server and get good separation of concerns without having to inherit from EFContextProvider which would cause problems with IoC and possibly unit testing/mocking. We have been following John Papa's Code Camper sample on Pluralsight which initially set out using a Respository/UoW pattern without Breeze which then led us to look at the Hot Towel template which does include Breeze.
Does anyone know how Breeze can be abstracted to a Repository which keeps the DbContext cleanly (if using Entity Framework) encapsulated. Also, what happens if you are not using Entity Framework and prefer to use another ORM such as nHibernate.
Thanks for posting here as I am sure others will ask this :)
If you don't use EF then you won;t get the automatic metadata creation that Breeze provides. You can certainly abstract the EF context into a Repo however, and still get the benefits.
The Breeze/Knockout ASP.NET SPA template shows the repository broken out. I believe there is a sample for the UoW somewhere - tho it escapes me where. I have asked the Breeze folks to point to an answer for that.
If you use nHibernate there is no automatic metadata - however that is a great feature request I could see for Breeze.
Since this article http://symfony.com/doc/2.0/cookbook/security/custom_provider.html has not been written yet, has anyone an idea of how to do that ? (In my case it would be using LDAP authentication).
Thanks for your answers
To help you get started you can check out my blog post which outlines how to create a very basic user provider system:
http://clintberry.com/2011/custom-user-providers-symfony2/
EDIT: This post only covers the custom User Provider. To use LDAP authentication you will need to create your own Authentication Provider as well or use a third party library. http://symfony.com/doc/current/cookbook/security/custom_authentication_provider.html
This first thing I would suggest you is to do a search for a LDAP bundle on the great website KnpBundles (results here). I saw two results. If you are willing to use an external bundle, you could just use of the two given in the results.
If you prefer to create your own bundle for this task, what I would suggest is to inspire you from these two bundles. Another useful suggestion is to check the FOSFacebookBundle. It is in no mean related to LDAP but, they implements their own provider, so all the glue is there to implement your own.
Just a small notice, if you are developing against Symfony2 master branch, it is good to know that security factory registration has changed a bit. So, be carefull when looking at other bundles to be sure what version they are targeting.
Hope this helps.
Regards,
Matt