Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User session lacking #3

Open
nisi opened this issue Nov 20, 2011 · 1 comment
Open

User session lacking #3

nisi opened this issue Nov 20, 2011 · 1 comment

Comments

@nisi
Copy link
Contributor

nisi commented Nov 20, 2011

In the case of a new Rental (any activitiy in general), the system user who creates the rental is saved in the activity. However, we currently do not have any way of identifying and setting the corresponding system user. Issue arose due to saving the creator of an activity while renting a medium.

Some kind of session or something, which is accessible in use case controllers, is necessary. I'm aware that user authentification will only be implemented in a later time box, but this'll server as a reminder.

@Danielku15
Copy link
Member

I'd recommend to create a AuthenticationController placed in the BusinessLayer below the UseCaseLayer (as planned) and access this controller from other usecase controllers.

This will solve the problem where to get the data from, but there's still a need of a session/context like behavior. My idea would be to implement a ApplicationContext class which stores singletons for all controllers. All usecase controllers get a reference to this ApplicationContext during creation. (Base class for controllers with a constructor for setting and a protected getter for accessing this context). Upper layers (like the RMI service) can hold an instance of this ApplicationContext and do the session management.

Example Scenario:

  1. The RMI client connects to the RMI API service
  2. The RMI client requests a new ApiContext from this service. (This ApiContext holds an ApplicationContext and UseCase Abstraction API classes)
  3. The RMI client calls login with LDAP credentials on the AuthenticationApi
  4. The AuthenticationApi class forwards the login request to the according AuthenticationController
  5. The AuthenticationController sets the "currentUser" property according to the credentials.
    (... some steps to setup a new Activity)
  6. The RMI client tells the ActivityApi to save the activity
  7. The ActivityApi forwards the save action to the ActivityController
  8. The ActivityController accesses the AuthenticationController via it's ApplicationContext and stores the data

ActivityController.java:

public void save() {
    if(getApplicationContext().getAuthenticationController().canDo(CREATE_ACTIVITY)) {
        throw new SecurityException("Current user does not hve the permission to create an activity");
    }
    currentActivity.setCreator(getApplicationContext().getAuthenticationController().getCurrentUser());
}

AuthenticationController.java:

public boolean canDo(String roleKey) {
    return _currentUser != null && _currentUser.hasRole(roleKey);
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants