When i click a link im calling a servlet.
When i click that link multiple time the servlet throws an error (error details not important)
Though there are other work around for this fix (Like disable the link once clicked, etc)
I am curious is there any way to control this thru request/response Object.
the error is relevant, having multiple calls to a servlet acting different then one means you have thread safety issues probably due to the way you implemented the servlet
The details of the servlet's error are potentially interesting. The servlet APIs in general should not be throwing errors, my guess is that this is an application error of some kind.
The general principle I try to apply is:
1). We construct the UI to make it difficlut for the user to inadvertantly submit the same request twice (eg. debit my account £100, really don't want to send two such requests. This is where some nift javascript can help.
2). We construct the application to defend against inadvertant double requests, for example by including some kind of identifier on the requests that allow is to spot duplicates.
We do not assume that the UI is perfect, our business application layer has final responsibility for preventing double actions.
The error is really, really relevant.
You could have thread safety issues but you can also have a "race-condition", that is, the result of the process depends on the execution order, one of them could give you an error.
(race condition : http://en.wikipedia.org/wiki/Race_condition)
Set a flag in the servlet session scope when entering the servlet and reset it when leaving. If the flag is set when entering, then silently ignore.
You will need error handling in your servlet so a ServletException does not leave the flag set.
Related
I have the same question as in the topic below, but I'm not so sure if my approach is wrong.
How do I know if a guard rejected a transistion
My app is a linear step-by-step strategy board game with several different game settings. I've decided to use Spring StateMachine to solve as in my opinion (and so far) it solves a lot little code-related organisational problems But now I'm stacked
The problem I have run into is that I can't say if my event passed all the guards and transition occurs. I just get true-flag when an event is added to the queue
The approach I'm following is passing data via event-context, validation of one with guards and apply changes using actions
transitions
.withExternal().source(SPEECHES).target(VOTING).event(VOTING_EVENT)
.guard(Guard.and(
guards.get(NoVotesFromSuspectedGuard.QUALIFIER),
guards.get(NoSelfVotingGuard.QUALIFIER),
guards.get(NoDeadParticipantsVotingGuard.QUALIFIER),
guards.get(NoVotingForDeadParticipantsGuard.QUALIFIER),
votingOutOfParticipantListGuardFactory.get(NUMBER_OF_PLAYERS),
guards.get(VotingBasedOnPreviousOneGuard.QUALIFIER)
))
.action(actions.get(CalculateVotingAction.QUALIFIER))
As I understand now, there is no possibility to notify event-supplier about failed guard evaluation. If so, just let me know and I will switch to another SM implementation. But if there is any possibility of solving my problem, please help me.
The behaviour I expect is any meta info of failed guard (to build formatted error message)
You can use some context flag, for example context.put("NoVotesFromSuspectedGuard", false) when "NoVotesFromSuspectedGuard" isn't success and then you can check this variable in your invoke code context.getExternalVariables().get("NoVotesFromSuspectedGuard", Boolean.class).
Also, in Spring State Machine you can declare ActionListener bean, which contains some different methods for StateMachine events monitoring.
For more information, you can see Habr(Russian)
I'm using Vaadin Flow to develop a web app with Java. I would like to know the best way to handle login and authorization. I've been giving this a thought and I'm not sure the best way to do this.
I have a login view and a main app view with a content holder for nested layouts.
How do I check that the user is logged in and what permissions does it have to see or not see some part of the app? I've read about BeforeEnterEvent and ReRouting but it's still not very clear.
Do I have to use BeforeEnterEvent for each class I have? Do I have to create a class with user parameters like a boolean to check if it's logged in and a string for the kind of authorization it has? And where do I create or save this instance?
Is there a simple way to do this? Like to start with an empty layout and to start that with the login screen, then the login screen decides to swap for the main app view? And how do I prevent the user to type the address of the main view in the bar and access parts it shouldn't access like: /app/adminsettings
I'm sure this is way simpler but I think I have my head overloaded by now, thanks anyone in advance!
As always, there are no silver bullets. The "best way" always depends on
the requirements and your options range from Basic Auth to some external
OIDC provider.
There are already some tutorials out there with the most prominent from
Vaadin itself about Spring
Security
(which in a previous iteration had a flaw that compromised security,
which of course shows again, that security is no product but a process
and demands constant validation).
So I want to strategize here a bit more about the problems you are
facing and some things to consider:
Be aware, that when you use a security library, that has or allows for
an web path centric approach, that you should only use it for the
root and to open up paths to resources etc. The history API may only
look like you are fetching URLs from a server or web sockets may be
used under the hood and suddenly those rules no longer apply.
If you are using the annotation based way to add routes, you end up
with all the routes, that are there, for your UI per user. So it's
good to familiarize yourself with how to register routes
dynamically.
E.g. only add the routes the user is allowed on login; this usually
also has implications for the UI (e.g. menu entries).
There usually is some initial "declarative" security part (can the
user even enter this view; this usually means some simple role check).
A good place to check for this is a BeforeEnterListener added to the
UI; it will be called before any navigation to any view. See
navigation
livecyle
The next entry point(s) to guard are the BeforeEnterEvent you can
listen on in the view itself and/or maybe it implements
HasUrlParameter. If you take params from the "request" or the path,
the usually mean further checks (e.g. is the acting user allowed to
edit the blog entry with the id 42). See routing and URL
parameters
and also navigation
livecyle.
Deeper into the application you end up with something more imperative,
that libraries often make appear declarative, because they generate
some code for you from some annotation (e.g. some AOP that generates
the code around your #SecurityCheck('${u.owner}==${currentUser}')
void save(User u) method, that checks for the role and whether the
User u belongs to the acting user).
Be very certain, that your IoC system/library/... sees those
annotation and generates the code accordingly. Only #Route e.g.
will get the full DI treatment with Vaadin+Spring - for the rest it's
your job that the DI-framework can do it's job (a NPE from a missed
#Autowired is spotted very quickly, but a security check not being
called, is not). The obvious way around this, is to be imperative and
write the code yourself instead of relying on it to be there.
If you have an anonymous system and then some login, make sure to send
users over to a fresh session (and therefor UI); not only does it
prevent a session fixation attack, but it also allows you put all your
route-setup and UI derivations according to security in one place at
the beginning of the UI creation. If you have state you want to carry
over, make it part of the URL, that your successful login process
sends them back to or park in the browsers local storage.
I'm trying to make an app that connects to Fitbit via OAuth2 using spring-social. I've had some troubles with this but I think I'm figuring things out. I notice that the OAuth process is initiated by making a POST to the ConnectController. Why is this done with a POST rather than a GET? I'd like to make it so that I can drop a link into a chatroom that the user can click to authorize my app to use their Fitbit information, which means that I'd like to start things off with a GET. Is there a reason why this isn't done? If I were to make changes to this effect (by subclassing ConnectController) would I run into technical/security problems?
There are 2 reasons:
The primary reason is that GET requests are expected to perform operations that are both safe and idempotent. But as a result of that request, you may (in the case of OAuth 1.0(a)) end up obtaining and possibly storing a request token as well as initializing the OAuth dance with the provider. This is not considered "safe" in the terms of a safe request. Moreover, it may or may not be idempotent, as repeating the request may result in a different behavior (depending the the provider's implementation of OAuth). While this may not apply to OAuth 2, it needed to be consistent between OAuth 1 and OAuth 2.
The /connect/{provider} path represents a single resource. There are only so many HTTP verbs to choose from without resorting to putting verbs into the path. The GET method for that path is already assigned to the request to fetch connection status for that provider (an operation which is both safe and idempotent).
Even so, I've encountered the use-case you're asking about. What I've done when I feel the need to have a link that kicks off the OAuth flow is to have a form that POSTs to /connect/{provider} and have some Javascript that submits the form for me, either as the result of a direct link (if the link is on a page in the app) or as the result of page load (if the link is to be given in an email or chatroom).
You're also certainly welcome to override ConnectController's behavior or even write your own implementation of the controller to meet your needs, even if they violate the reasoning behind why ConnectController is implementation the way it is.
We have built a Spring MVC web application that is heavily relying on the user to do things in a certain order, and while it prevents users from circumventing this (without trying very hard) in the usual case (by not offering options to “go to places” you’re not supposed to at the given moment), we’re having some problems when people open another instance of the application in a new tab or browser window.
Since the application stores the domain model in the user’s session, using the program in another window can potentially mess up the model’s data, we’ve already implemented a page-ID mechanism that validates the user using the program in the correct order and not using the browser navigation, but we’re still facing problems when things like resetting the program (this is a feature, redirecting the user to the home screen and clearing the domain model) happen in one window and the user then tries to do something relying on the domain model to be filled with valid data in another window (leading to a NullPointerException quite quickly).
Storing some user details (like id, name, email) in a session might be ok, but storing the user's state (or any data that changes often and/or significantly affects other things in your app) doesn't sound like a good idea.
Hopefully one of the following approaches will fit you:
Don't save state in the session - load it from the database whenever you need it (in your case, whenever the user tries to access one of the steps that should be done in order). If you use caching, this shouldn't have major performance consequences.
Don't save state in the database, only in the session - works for limited cases (for instance, ordering airline tickets) where you can postpone committing your domain object until the process has finished.
Use Ajax for multi-step processes and don't save state at all (except implicitly in the browser). This requires putting all the steps into one page and ajaxifying some of your code.
Regardless, if someone logs in and tries to go to step 3, they shouldn't get an exception thrown at them, but that's a different story.
If I were you, I'd let user to wander around other parts of the website - the parts that don't interfere with your wizard process. However, once they try to restart it - check if there's PageID in session, and remind them they have not finished what they started, and ask if they would like to cancel/restart or continue on from where they left it.
In case anyone ever reads this question again:
Instead of the HttpSession keeping exactly one copy of the domain model it now holds a collection and we transport a reference to a single one of the models through the requests/responses so we can get the right model to work on in our controllers and views.
I am developing a medium size Java Web Application with Struts as MVC framework and simple JDBC at Data Access Layer. I have been searching for exception handling best practices in such an application. I have found several articles, some of them being contradictory, only making me more confused rather than making things clear and simple. Some say it is better to reuse existing exceptions instead of defining application specific exceptions, others present a huge hierarchy of application specific exceptions for every minor trouble that may occur in the system. Some say it is better not to handle exceptions at Data Access Layer and delegate them to the Service Layer, others say Data Access Layer exceptions should be caught locally since delegating them to Service Layer would violate the abstraction between the two layers. And so on.
I would highly appreciate if you let me know of links/names to articles/books that present solid solutions which have worked for you in such a scenario. The solution should clear at least the following points with justifications:
Where the SQLExceptions be caught?
Where exceptions should be logged?
Should unchecked exceptions be logged?
Should unchecked exceptions be caught at presentation layer, and should they be shown to the user?
How checked exceptions be handled, which of them to be shown to the user and how?
How should a global exception handler page be used?
How should struts ActionErrors be used in this context?
Thanks
1: Where the SQLExceptions be caught?
In DAO classes in data access layer. You can if necessary wrap it with a custom DAO exception. This DAO exception in turn needs to be handled further as checked exception.
2: Where exceptions should be logged?
At the moment when you're about to throw them or to pass through the messaging framework.
3: Should unchecked exceptions be logged?
They should certainly be logged. They should namely not occur in real world, because those are sign of a fault in the code logic (i.e. developer fault) which needs to be bugfixed asap. They should be thrown all the way up to the container and let the container handle them with an <error-page> in web.xml. To log (and eventually mail) them, use a Filter which listens on the error page.
4: Should unchecked exceptions be caught at presentation layer, and should they be shown to the user?
They should not occur at all.
5: How checked exceptions be handled, which of them to be shown to the user and how?
If they are result of errorneous user input (e.g. not a number, bad email, constraint violation, etc), show them in the same form to the user. Otherwise (e.g. DB down, DAO exception and so on) either throw it all the way up to the error page, or display the error with a message to try again later.
6: How should a global exception handler page be used?
At least in an user-friendly manner. Thus, in the same layout, with some introductory "sorry" and if necessary with some error details and an email address so that the user can contact for the case that.
7: How should struts ActionErrors be used in this context?
Show them in same form to the user.
If you can't recover from an exception, then you should let it flow out of your code (often by making it unchecked, or wrapping it in an unchecked exception). If they remain checked, you have to cater for them at each level of your code, and consequently at every abstraction layer. SQLExceptions would normally fall into this category (you'll have to wrap them since they're checked).
For these exceptions, I normally log at the highest level, but present a page to the users simply detailing that something has gone wrong. Normally my users aren't interested in stack traces. But I usually offer them a page to let them describe what they were doing at the time, and the logged exception ties back to this submission via a unique id (recorded in the form and in the log file with the exception). That allows me to tie back users' actions to the resulting exception.
The above assumes that you can't recover from SQLExceptions, and if the database is down, then you can't do something meaningful. There are exceptions to this, of course. You may find that you're talking to multiple systems, and one being down doesn't mean you can't continue in some fashion (e.g. the Amazon home page reportedly relies on 100 services, and needs to run regardless of some of these being down).
I would expect declared exceptions to be at the same level of abstraction as the interface/methods defining them. e.g. a TradeStore would be declared to throw a TradeException, not a SQLException (since methods of storing a trade are an implementation of TradeStore - you could store in a relational db, a JavaSpace etc.).
As a warning, when displaying lower level error messages to users, make sure they're sanitized of system information. This is an area where many security exploits originate. Log them with full information, but only display a more general error message to the user.