I need to implement User lockout in my web application which uses DatabaseServerLoginModule and JBoss5. I am planning to write a custom login module class to achieve this. My next question is: where should I put my custom login module class? After some research I found couple of solutions:
Deploy the login module class in a JAR as a standalone module, independent of the webapp
Deploy the login module class as a part of the webapp in a JAR inside WEB-INF/lib/
My web application will be packaged and shipped to the customer and customers install this package and JBoss separately on a Server. My question is: Where should I put my custom login module class?
Any suggestions will be really helpful.
If I were the data center, I would expect two packages:
One containing the login module
and another one for the real application
Reasons
The data center might have special responsibilities regarding sensitive user data, authentication etc. So in case of a login module, they might even have a special internal review process (this is normally not applied on an ordinary application). In order to avoid this review with each application update, a separate package is preferred. In order to have a quick review, a small package is better.
There might be other applications which use the same login module
A data center must be paranoid: An application which ships with it's own authentication could be abused to install a back door. Again internal or legal requirements may not even allow it.
Related
I'm currently developing a project in Node JS that uses microservices architecture, in which each service has it's own repository that contains both the code for the service itself (NodeJS express server), and also an SDK file that I publish for other services to use with methods that are available in this service and Typescript definitions.
So for instance I have a users-service that handles all of the user related actions, and a reports-service that handles all of the reports that users can CRUD.
users-service has a method called "deleteUser" that also goes to reports-service SDK in order to delete all of this user reports. On the other hand reports-service uses user-service SDK to "getUserById" for instance. So what happens is that user-service has reports-service-sdk as one of it's dependencies, and reports-service has users-service-sdk as one of its dependencies. Because the SDK is inside the same npm module with the service, I get users-service-sdk as one of the dependencies of users-service.
I thought of separating the SDK with a different package.json file, but I wanted to know if it's the right way to go or am I doing something really wrong in my architecture :)
Thanks.
This sounds like Circular Dependency which as you stated in the title is tough to deal with. Microservices are great but this sort of architecture sounds like a lot of extra unnecessary work without any added benefit.
You should look into running your services/packages/repositories as Cloud functions (or Firebase functions). AWS also has their own solution for microservices architecture. The reason being is each service can communicate with other services by using internal authorized calls or authorized REST API calls --- or you can make them totally public.
The great thing about these Google Cloud Functions is each function is automatically an Express end-point that accepts GET, POST, DELETE, PUT. Or if you use the internal call for Firebase, each function automatically contains relevant context from the frontend (such as the user's authentication details).
You also configure IAM permissions to only allow who and what service you want to be able to execute your cloud functions so that you have full control of permissions.
To answer your questions directly though, I would definitely avoid Package A having Package B as a dependency as Package B has Package A as a dependency. You absolutely can make that work but there's no upside and a lot of downside.
Here's an old thread which covers the topic.
I have defined two entities:
entity Company {
name String required
}
entity CompanyAddress {
street String,
number String
}
relationship ManyToOne {
CompanyAddress{company(name)} to Company
}
After running jhipster import-jdl two new entities are created company and company-address
What i want to do is to display list of addresses of a company in company-detail.component
When i place in company-detail.component intellij idea instructs me to import company-address module.
When i do that, application routing doesn't work correctly any more, because i am not able to go to company component from main menu, instead i am routed to company-address.component.
So, what is the correct way to achive this?
Thanks
An Angular application can have one Router-Object. You create a router module and a service in the app root module. The SPA can have one or more router-outlets, where linked components will be rendered. These components can be loaded with the root app or lazily to keep the initial size minimized. Lazy-loaded components can be preloaded. And the Router can be passed with or without data to its child.
The child component can add its routes-configuration to the Object. The Router is also dispatching events, which can be intercepted. And the routes can be guarded (e.g. "only allow logged in users to render the linked component").
JHipster generates a best practice "template" Angular frontend (if chosen), which is of course complete and ready out of the box to fully use the generated Spring backend. With all features like centralized configuration, authentication and protection measures all over the application, translation, the possibility to fill, update and read your databases with the frontend and/or an API, dev- and prod-configuration and a lot more you have to think of to build a scalable, extendable, business-proof up-to-date application, monolithic or in a microservice architecture.
Additional tasks, another opinion in user guidance and operability etc. of your application may have to be implemented on your own. JHipster shows you how to do that in an opinionated way and will lead to good code. With JHipster you get the knowledge from a lot of experienced full-stack developers in your hands - for free! It's miraculous what they're doing!
Try to build side-by-side to be able to use generator-jhipster not only as initial generator but also to stay up to date with your app with the help of the JHipster upgrade feature. Code often has its decay period, opinions do change - Hipster stay up to date.
Or use JHipster to test your ideas fast and comprehensive.
Or use it to learn what have to be thought of to build professional applications.
I am tring to make CRUD operations on Active Directory via nodejs.
The only package that handle CRUD operation in node that i have found is ad-
https://www.npmjs.com/package/ad.
Are you familiar with other packages?
Is this the only one for update operations?
It seems that integration with Active Directory in nodejs is not popular and mature. Am I wrong? should I implement such integration in Java or .Net core?
Thanks!
The right way is the way that works :) If you are already using NodeJS, then do it in NodeJS if at all possible.
Communication with AD would happen through LDAP, so you can look for NodeJS packages for LDAP. Here are a couple I found:
ldapjs
ldap-client
But that one you linked to is more specific to AD (and AD does have its own flavor of LDAP) so I would choose that as long as it works for you.
If it doesn't work for whatever reason, either ask a new question here to get specific help, or you can start looking into making a separate Java or .NET app to do it. But I wouldn't consider a separate app just for AD queries unless you absolutely couldn't do it in NodeJS.
I am working on hyperledger composer
after deploy bna file to server it will automatically create angular UI when we connect to angular through fabric server
now my question is is there need to create jsp/angular/jsf whatever files to dispaly UI(client) like login web pages or it will automatically generate???
If you are using the angular generator via Yo, then what is generated is a simple angular example. It's intention is not to generate a complete working application but to provide you with a starting point from which you can tailor to meet your needs. For example the generator can only handle simple models and cannot handle models that contain concepts. It can only interact with a rest server that doesn't have authentication enabled or multi-user enabled.
In answer to your specific question about login pages, it won't, you will have to add this kind of capability yourself.
I'm new to Haskell and Snap and I want to write a simple bug-tracking application. I set up a Snap project using $ snap init and it works. The problem is that I don't know how to go any further.
I want to create a snaplet Tickets that uses a database to store bug reports, and use that snaplet in my main web application.
I read the documentation about snaplets but I couldn't figure out where to put their source code (in the /snaplets directory, I suppose? If so, how do I load them?). Could anybody point me in the right direction?
Are you sure you need to create a separate snaplet for Tickets? The snaplet infrasructure is meant for reusable components such as session management, authentication, database access, admin panels, user management, etc.
Are you going to be using your Tickets self-contained module across multiple web applications? If so, then by all means go ahead and create a snaplet.
In any case, it sounds to me like you are at least in part asking how to organize a project with multiple "modules" or "parts" while using snap. I'll try to address this below. Please let me know if you feel I have missed the mark.
Assuming you don't need to create a separate snaplet for Tickets:
For functionality specific to a single site, I think you would be better off creating a few modules and developing the code for the functionality right inside your current application's package and module hierarchy. Here are a few points on how I have been organizing my snap projects of late:
I put my database-related code under modules in MyApp.DB.
namespace. You could have a MyApp.DB.Tickets that contains all
database calls needed for operation on your Tickets module.
I put all UI-related functionality under MyApp.UI. namespace. You
could put a MyApp.UI.Tickets module that contains your Handlers,
your Splices, your Forms and so on.
To handle forms, I use the excellent digestive-functors library. You may find this blog post helpful if you don't know them already.
I usually have a shared UI helper library under MyApp.UI.Helpers where I place common code used across all/most UI modules.
I usually have a shared Form helper library under MyApp.UI.Forms
Any code tangential to the fact that my application exposes a Web UI goes outside the MyApp.UI. namespace. So if my application needs to perform some offline analyses, I may put them under the MyApp.Analysis. namespace.
Once you define and export your Handlers under MyApp.UI.Tickets, you can go to your Site.hs file and wire them into your application at specific routes.
For inspiration on how to handle database connections, you can check out the postgresql-simple snaplet.
However, if you do need to create a snaplet:
A snaplet is simply a stand-alone application that uses the Snap.Snaplet infrastructure, (typically) has its own .cabal file and (typically) is its own Haskell package. Snap then gives you a way to embed or nest this re-usable, self-contained application in yet another snap application. Think a hierarchy of Russian dolls.
Assuming you performed something similar to what I described in the section above, you are now 95% ready to convert to a snaplet. Just name your application snaplet-tickets, expose a SnapletInit using makeSnaplet and use nestSnaplet in another snap application to include this reusable piece of functionality right there.