We Keep Coding

Domino java xpage - caching values server-wide

I have a Java XPages application with a REST service that functions as an API for rooms & resources database (getting appointments for specific room, creating etc).
The basic workflow is that an HTTP request is being made to a specific REST action, having the room's mail address in the search query. Then in the java code I'm iterating over all documents from the rooms & resources database, until I find a document with the InternetAddress field with the searched mail address.
This isn't as fast as I would like it to be, and there are multiple queries like this being made all the time.
I'd like to do some sort of caching in my application, that when one room is found once, it's document UID is being stored in a server-wide cache so next time a request is made for this mail address, I can directly go to the document using getDocumentByUNID(), which I think should be way faster than searching over the entire database.
Is it possible to have such persistent lookup table in Java XPages without having any additional applications, while keeping it as fast as possible? A hash table would be perfect for this.
To clarify: I don't want caching in a single request, because I'm not doing more than one database lookups in a single query, I'd want to keep the caching server-wide, so it would be kept between multiple requests.

Yes, it is possible to store persistent data. What you are looking for is called an application scoped managed bean.

how to store images on server so that image path with id can be store in a property file as map so that we can get images based on id

all I am new in java I am working on a spring MVC, hibernate, MySQL base project and
I want to store images in a specified folder/directory on server so that I can manage a property file(file name may be something) in which I can store image path with id as map(key as id and value as image path) in that property file and also I want to take some other information from database table also that might contains other image information like uploaded date and description, etc. so how can I do this.
Thanks in advance

If I am not wrong, I got your problem - "You basically want to do two things, first a property file that contains the image location mapped to a key, second manage information related to an image such as upload time and description", so here how I would do it -
I would not recommend you to maintain a properties file due to the fact that CRUD operations will not be that convenient. Also the data you would like to maintain are not properties, these are real-time / dynamic data where your design should have a very good control. You are already using hibernate and MySQL, so why don't you think of maintaining a table (a hibernate entity) that replaces your properties file and also it would be easy for you to maintain other information like upload time and description. All these can be properties of your entity. Moreover you can define relationships with other entities, if required. Coming to the CRUD operations, awesome APIs of hibernate is in rescue. Think about test-ability as well, your design will be easily testable with this approach.
I am already doing this in one of my company project and it's not so bad design.

Optimal way of storing current user data over multiple classes

I have a login page which connects to a Database, the Database has only one client, when a user logs on he/she may make certain changes to his profile and then save. A large number of frames require the current user id in order to manipulate his data
Among the possible ways of storing the user currently logged in is
1) to save the data to a temporary text file and persist it before the user logs out
2) another option would be to use variables across all the frames ,however I'm not too confident about this
3) a third way would be to have a Boolean column in the database and to persist the the data of the field with true in it
Perhaps there are better ways of storing the current user Id could somebody elucidate other possible methods and highlight the pros and cons of each implementation with reference to an "optimal" method of doing this
Edit: This is a desktop application

I would suggest not to share this information in any static context for the reason it will render your project as very hard to test once it gets big enough. See this link for more info: When to use singletons, or What is so bad about singletons?
What I would do is store session objects in some map, identifying the appropriate session by an ID that will be given and sent back to you via client cookie. This is how the web has been doing it for years, and it is still doing it this way. Simply pass the session object around to any class that requires access to that data when it needs it.
If you are using a J2EE implementation, then you may already have support for sessions within that implementation, you should check out "How to Use Sessions"
This is more of a software design question, and covering the basis to complete the patterns used to support what I just suggested is unfortunately beyond the scope of the question

The logged user is an instance of the class Person or LoggedUser.
You have to instantiate it and share its reference between Views via a Model.

encrypting hidden variables in JSP

We've got user SSN's in jsp's that show in source code of an html page as:
<a href="onclick:submitsomeform(123456789)"
In order to avoid this, I made couple of methods called getEncryptedSSN() and getDecryptedSSN() which could be called from the JSP. These methods made use of the javax.crypto to encrypt/decrypt the ssn string, however, this import is "disallowed" by the setup coding standards. So now I'm out of options on how to avoid showing the SSN in the view source of HTML. We can not go the route of not passing the SSN in form submit because in the DB, the SSN field is the only primary field.
Are there any other ways to simply encrypt/decrypt a string in java w/out using javax.crypto?

Obviously, having an SSN as a primary key is bad -- but you may not be able to change this.
Have a look at this OWASP page: Insecure Direct Object References:
Preventing insecure direct object references requires selecting an approach for protecting each user accessible object (e.g., object number, filename):
Use per user or session indirect object references. This prevents attackers from directly targeting unauthorized resources. For example, instead of using the resource’s database key, a drop down list of six resources authorized for the current user could use the numbers 1 to 6 to indicate which value the user selected. The application has to map the per-user indirect reference back to the actual database key on the server. OWASP’s ESAPI includes both sequential and random access reference maps that developers can use to eliminate direct object references.
Check access. Each use of a direct object reference from an untrusted source must include an access control check to ensure the user is authorized for the requested object.
I have used the Access Reference Map from their ESAPI -- it was pretty straightforward. Our unique IDs were simply replaced with random strings, which were tied to a user's session.

One obvious option is to just write your own encryptian function. You probably aren't going to write something as secure as the big-time security folks have come up with, but depending on the context, something simple might be adequate, i.e. something that would frustrate the casual snooper, and accept that if the CIA or Mosad or whoever is trying to crack your encryptian, they'll figure it out in minutes. I don't know how big a target you are for hackers. If you're working for a bank or the IRS or something where lots of people might well be trying to intercept your transactions and the consequences of interception are high, forget it, you want industrial-grade security. But if you're working for Joe's Pet Care Advice Swap Forum and there's no particularly sensitive information involved other than the SSN itself, and there's no great number of enemies out to get you, a home-grown solution might be adequate.

You should be encrypting your SSN on the database side due to its sensitivity. SSN should not be stored as plain text values because they are fully visible for hacker access. Look at SONY, and the many more companies getting hacked.
I would say encrypt them in your database using database encrypt functions. I don't know what database you are targeting MySQL or Oracle or etc). You then can just use the encrypted SSN from the database. Here is a mysql reference:
http://dev.mysql.com/doc/refman/5.5/en/encryption-functions.html

Is there any security concern with displaying the Key value to users in a URL?

I am using the Key value of entities in my datastore as the unique identifier in the URL for pulling up a record:
http://mysite.appspot.com/myaction/1x7s3fgdlbnRlcklkcicLAbcXc2VyQWNjb3VudCIFYW9uZ
This is not a very attractive solution, nor is it SEO friendly, but it's the easiest way I've found to identify an entity uniquely in App Engine/Java.
My main concern, though, is whether there is any security concern related to displaying the unique Key value for the entity?

The encoded key contains your app ID, namespace (if any), entity kind name, and key name or ID. There's two possible issues here: the disclosure of that information (probably not problematic), and the fact that you're accepting an encoded key. If you don't check that the entity specified by the key being passed in is of the correct kind, and that the user should have access to it, then they could pass in their own key to cause you to disclose information you shouldn't.
Almost universally, however, you already know the kind name of the entity you're fetching, so a much better idea is to use just the key name or ID of the key, and construct the full key on demand. This also makes for much cleaner URLs.

The security concern is that a potential hacker knows something, however small, about your database.
If parts of your database are ever compromised the entity id could prove useful for the hacker.
Like you I don't really like displaying database IDs but IF you secure your application properly it isn't worth worrying about as knowing the entity id isn't going to be useful.

Are you sure that's an actual key? It doesn't look like one (the un-base64'd data generally includes your app identifier, for one).
The documentation covers it, though:
Note: A string-encoded key can be converted back to the raw key data. This makes it easy to guess other keys when one is known. While string-encoded key values are safe to include in URLs, an application should only do so if key guessability is not an issue.
It's a lot cleaner to do something like this:
foo = FooModel.get_by_id(int(foo_id))
That doesn't stop attackers from guessing IDs, but at least it doesn't fool you into thinking that IDs are "opaque" (and you can trivially change the ID to test access control, instead of needing to mess around with base64-protobuf-encoded data).

This is not a security concern in my opinion. Lots of sites use id as identifier within the site. A key is just a key to a row in a database table, you do want to refrain from showing much detail about your database in terms of table and user accounts etc.
In this regard, you want to prohibit your site from dumping out database errors when they occur, catch them and handle nicely.