Skip to content

Instantly share code, notes, and snippets.

Created January 10, 2018 08:18
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
Star You must be signed in to star a gist
What would you like to do?
Copy link

Hi Adam,

I have custom authentication filter that implements and sets my security context in requestContext.setSecurityContext(...). I can easily access this user in each REST endpoint by injecting @Context SecurityContext securityContext. How can I integrate this with EJBs, so that I can get the same user principal also in EJBs injected into REST endpoints? I expect, that in @Stateless I inject @Resource SessionContext sessionContext; and calling sessionContext.getCallerPrincipal().getName() should give me the same user. Doesn't look like it's integrated out-of-the-box in JEE7. I don't want to pass my Principal explicitly in each call to EJBs. What would be the best approach here? Thank you!

Copy link

omega09 commented Feb 5, 2018

Security questions:

  1. What would you recommend for authentication over SSL/TLS? OAuth/2, JWT? Why is it a bad idea to resend the password on each request?
  2. What is your checklist to have when writing code on both client and server which sends and receives sensitive data like credit card information? What security measures need to be instated?

Copy link

ghost commented Feb 5, 2018

What do you think about NetBeans future?
The same transaction to Apache was done for Open Office and... current situation is not good for Open/Libre Office :(

Copy link

Hi Adam, thanks for this monthly opportunity to raise questions.

Following your warning that Data Transfer Objects are widely overused we'd like to check if that is the case in our environment. We're starting to use JPA these days and it is a good oportunity to review our approach:

  • For us it is typical that more than one hundred applications (different EAR files) call (most of them via the remote interface) to the same EJB responsible for dealing with a set of database tables. For that, these applications use a client jar that includes DTOs to communicate with the EJB.
  • Our DTOs are most of them identical to the JPA entity: same fields, no impedance. We don't need to adapt incompatible domain layers
  • We've tried to substitute the DTO with the JPA entity itself (I mean, duplicating it) but we get the following exception because the JPA entity in the client jar has different bytecode (I suppose) than the one in the EJB that is enhanced due to weaving
    java.rmi.MarshalException: CORBA MARSHAL 0 No; nested exception is: org.omg.CORBA.MARSHAL: cannot locate RunTime CodeBase

Any recomendation for this scenario is welcomed.

Copy link

vanuatoo commented Feb 5, 2018

What is your approach to this scenario:

There is an Entity with columns: ID and Name. Name is annotated as @column(unique = true)

There is a REST Resource which injects session bean.
POST Request is sent to REST Resource which invokes business method in a session bean.
In a session bean there is a line: em.persist(bean);

The goal is to throw business exception from the session bean when Constraint Violation happens in the database but the exception is not thrown unless you put em.flush(); after em.persist();

Is putting em.flush() a correct approach?
Another approach would be to first find an object with the same Name, but there is still a chance Constraint Violation happens in a race condition.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment