Is there a efficient way of creating an activity log for a user. When the user changes the data log it, when admin changes there data log it and so on. Only way Im thing of doing this is posting at every api request.
One option is to log every single method that you want to be logged.
If you want to save time you can look at Spring AOP which allows you to extract a cross cutting concern, such as logging, into a seperate configuration file and then you can target a whole set of methods based on whatever criteria you choose (pointcut).
https://www.baeldung.com/spring-aop
Related
Where should I put on when to log the actions of the user, on Domain, or Presentation layer?
If Presentation Layer (Assuming MVP): After the presenter calls the interactor/usecase, it will call another usecase to add an activity/history log.
If Domain Layer: After the interactor/usecase itself does the action, it will save to the history/activity logs storage.
I'm confused if history/activity log is part of presentation layer as the text/action that will be log (eg string: User like this comment) looks like not needed on domain layer.
But I'm also confused if history logging is part of an application logic, which is Domain layer. Because if I'll put it on Domain layer, the log text format will be hard coded on usecase/interactor.
It depends what you want to achieve. If you just want to collect which UI elements and which parts of the UI are used by the users most often, adding the logging to the Presentation Layer might be sufficient.
If your focus is on logging which functionality is used by your users most often and how it is used then logging should be in the Domain Layer/Application Layer. In this case the decision which information is logged for each "activity" is part of the business rules.
You may want to use something like a Repository Pattern to keep the Domain Layer independent from the actual writing of the log.
i am working on a chatbot and need to save context of the previous conversation so that it can be sent to the next message. Now i m integrating it with facebook where facebook doesn't send context and need to store this context somewhere in a server. my client doesn't want to use DB. i tried sessions but technically i dont have a UI (facebook is the UI) . Next i tried ehcache but not able to retrieve data of previous webhook calls. Please let me know if any there is a method to store data and retrieve it latter without using DB.
What you describe is not really a cache usage from what I can tell. That is you do not want to have entries disappear (eviction) and they do not get stale (expiration).
If that is correct, you will need to use the appropriate in-memory data structure so that you can store that information.
being more specific would require a bit more information about your system, the volume of data (per entry and max entries at once), etc ...
Above image is the springsecurity.xml file.
Above image is the folder wise I written.
I hope what you are trying to achieve is restricting access based on user role. You can intercept each incoming request and check if the user who is trying to access the url has required role to perform this operation. Please read this link and develop your logic.
I'm currently working on a iphone/android project where the mobile talk ta java backend server through REST API calls.
The Java backend is done using Spring and its Authentication system (with a JSESSION ID token)
I'm not an expert in security but I can see that if not implemented correctly there could be quite a lot of issues.
One of my biggest concern would be user creation for example.
When the app creates a user it simply makes a POST request to (url.com/rest/create)
How can I avoid, server side, that a malicious user puts this url in a loop and create thousands of users ?
What are common best practices to secure API calls ?
Is the Spring Authentication token enough ?
Thank you!
It's not really possible to prevent a client from making many calls to your server. A malicious user can create a script or application firing requests to your server.
The solution is to authenticate and authorize the calls to the server. You give certain users (for example administrators) the privilege to create users. You trust those users to behave in a correct manner. You have your users authenticate before they call the APIs on your server. Then, on the server side your check who the user is and what he/she is allowed to do.
If you are still concerned about privileged users not behaving, you can assign quota to each user on the actions they are allowed to perform.
The hightech solution (with as much framework fuctions as possible) would be
first: have a created-by and created-date field at the entity you want to protect (I recommend to use Spring-Data-JPA Auditing for that).
second: create a custom spring method (or web) expression method that is able to check how many items the current user has created in the (for example) last 10minutes and if this are more then (for examle) 20, then return false (or make them parameters of the method).
Then you can protect your method (or url) with that expression (#PreAuthorize("createsNotExeced(10, 20)"))
But this is the high tech solution - it would be quite intresstion implementing them when one wants to learn spring security. (and you would need to add some caching, but this is also a Spring feature).
The lowtech solution would be: put an list of timestamp in the users session, and add an new item to that array whenever the user creates an new item. When the last (for example) 20 timestamp enties are within the last (for example) 10 minutes, then throw an TooMuchHeavyUseRuntimeException or somthing else.
We're moving from LDAP based authentification to SSO(Oracle's WebGate).
Right now for LDAP based we are using form based authentification with (UsernamePasswordAuthenticationFilter) at FORM_LOGIN_FILTER position.
For SSO user will be pre authenticated and request header with his username will be send. I plan to use RequestHeaderAuthenticationFilterat PRE_AUTH_FILTER position.
Problem is that we need to have both these filters to be present at the same and ability to switch between them based on value in property file. This is for scenario when SSO doesn't work as expected on production so we could easily fallback to LDAP.
My question is how to properly implement this. Will be there any side effects if two filters with these positions will be present at the same time? Is it better to extend both these filter and add property check in inherited classes or is it better to created composite filter which will handle switch between them?
Since the form login filter only processes requests at a specific location (e.g. /j_spring_security_check) having it in place shouldn't affect the function of the other filter. So your original question as stated is rather easy. The more important question that you should ask is how to handle unauthenticated requests. You need to decide how that will work in your new SSO solution and see if you can build something that you can use to switch back to display the login form in your app (and you need to design how that decision would be taken - e.g. a flag in a properties file or a runtime decision). If you are thinking in terms of a fallback that you can put in place at short notice, but don't mind a restart of the app, then I would suggest a Spring profile.