0

I have a sort of challenge with a development, basically I need to authorize the user to go/call to certain page/functionality using a token, those pages can be set to require authorization by demand (perhaps setting a param in a database).

The application was made with Struts 1, so what I have been thinking is just intercepting the URL using a filter, check if the request needs authorization, send the token via e-mail and redirect the user to the "insert token" page, then again intercept via filter if the referer was the token page and validate the value, if correct, then redirect to the original request...

However I can't simply recover the previous request, also the filter intercept the ServletRequest and Struts has a more detailed construction, so I can't loose the action or the form objects.

I'm not sure if this is a good approach to solve this need, if so, I need to keep the original request in memory and I'm not sure how to do that.

This is a legacy project and has a lot of pages and controllers, so it's almost imposible just going through every method doing validations.

I would accept any suggest, have a nice day! :)

EDIT

To add more context, the project has many forms made with Struts, so internally Struts map the html form to a POJO, to get them as parameters in the actions's (controllers) methods: ActionMapping and ActionForm. When I create a filter, my params are ServletRequest, ServletResponse and FilterChain objects, directly I don't have the ActionMapping or the ActionForm, but I know they are part of the request structure, so since I don't know how to get them directly, I'm trying to work with the whole request, hence the security and size issues, and also because I don't know how to store a copy of the original request while I'm doing the redirect operation

KESO
  • 335
  • 2
  • 5
  • 17
  • Just to clarify: "store the first HTTP request as a whole and retrieve/use it in the filter before the second request". Is this correct? –  Mar 09 '18 at 21:34
  • The second request happens when the user is finally sending the token that was asked when redirected, there once I perform the validation, I need to let the the user continue with the original request – KESO Mar 09 '18 at 21:40
  • If you find the answer to the question satisfactory please close it so the other members of the community can benefit. –  Mar 12 '18 at 03:58
  • @HosseinPursultani once I got it I will, this problem is my priority right now so I'm still working on it – KESO Mar 12 '18 at 13:54

3 Answers3

0

Given the amount of information Struts likes to pass around, I would be tempted to keep a session somewhere safe for the user's return. This post talks about a similar idea, though you could possibly just keep the sessions keyed by token.

Aware this idea would depend on the environment though, e.g. how quickly the user is expected to come back with the token, and the total number of users this needs to scale for.

df778899
  • 10,703
  • 1
  • 24
  • 36
  • Well the users are not going to be all the time sending tokens, however I'm a bit concerned about saving session objects (where) and because I will need to keep in the user side a kind of session id. Can you give me a more detailed example of what you suggest? – KESO Mar 09 '18 at 20:27
0

I would have considered encrypted HTTP cookies (if your application privacy policy allows cookies).

You can store the required information for later use and expire it after a while. Also, you don't need to be concerned about session storage and scaling. Seems to me fits the bill.

Having said that, there're details that you need to consider. In particular cookie encryption.

Update

A note on big objects in cookie. Creating big HTTP header is not always a good idea. Most web servers even force a maximum on header size (see Maximum on http header values?). You need to serialize the binary data in Base64 encoding which makes it even larger.

If your objects really big (like Struts constructs) that can't fit in the HTTP header. You probably don't want to store them in your in-memory session either. You might want to consider a database backed session if feasible.

Tomcat (if this is your web container) has one JDBCStore and you can configure it. It's not great though, having a database query on each request/response.

An alternative to storing all sessions in database, is to only store that particular object in database and store its associated key in HTTP cookie. This is what I would probably do given the size of the object.

This is basically a trade-off between memory and speed. (I don't know the exact requirements of your application in terms of resources and performance).

  • Seems interesting, however since this is Struts, I'm not talking about few simply params but complex objects (actions, forms), I'm not very sure cookies can handle this, have you ever try to "store" a big objet in the user side? An example could be handy – KESO Mar 09 '18 at 20:36
  • I can't tell off the top of my head. By storing very big objects in the cookie might be problematic. Same as the session, esp. in-memory session. I'll update my answer. –  Mar 09 '18 at 20:56
  • Okay I will also update the question to add more details. – KESO Mar 09 '18 at 21:12
0

After few days looking for a properly solution, I have decided to change the idea, instead of rewriting (in a very unsafe way) the request, I designed a two side solution, from the frontend side I intercept any request using JavaScript, I do an initial validation of the URL and then ask for the token, so finally I'm sending an additional parameter that I can get in the filter, and then after doing the validation, I can continue the original request or create a redirection. Thank you all for the time and suggestions, I think is better explain what I did instead of leaving this topic in the air.

KESO
  • 335
  • 2
  • 5
  • 17