Develop Reference

OIM 11gR2 PS3 Save Justification of Request on Create User

In OIM 11gR2 PS3, When creating a user I want to save the String entered in the Justification box of the request. When creating the user I have no workflow set, because I don't need any approvals. Do you know any way to do this??
Thank you

I found out that the best way to retrieve the justification of the request on create user is not through the API, but querying the DB and getting the justification field from there, given the login of the user. I also ordered the results by date, in order to retrieve the most recent request.

Spring logout problem

I have an application which is validating only one user should use the application at a time. For that we are putting a column in DB table. By default the column value is 'Inactive'. When the user logged in, column value will be changed to 'active'. Once the user properly logged out, the column value will be changed to 'inactive' and the session gets an end. But when the user close the window improperly, the logout code is not working. I tried with onunload but the problem with the onunload is since we are using tiles, each time when we click a link log out is happening. So can anyone help me how to do it while closing the window directly?
Thanks in advance...

You should not be keeping an entry in DB to track whether the user is online or not. Instead you have to keep all the user names in the application context and whenever the user logs in, you have to check if the user name is already in the application context. If not, add it to the context, else the user has already logged in.
Having a DB column to know if the user is active or not is a very bad idea. If at all this is used, you have to call an event using javascript every time you close the browser window. Also it might so happen that because of some network problem, the window close event will not be intercepted by the server resulting in the user being still shown as active in the DB

User Authentication and User Accounts - Basic Programming Techniques

I think the answer to my question is so simple that there's not even an answer to my question lol:
How does the concept of User Authentication/User Accounts work? How does a certain webpage, for example, know to pull up your information and not someone else's when one logs in? Is it really just a bunch of select statetments with a where clause on the userid to pull back info?

When you connect to a website, a session cookie is placed in your browser. This uniquely identifies you so that the website knows from request to request, page to page, that you are the same person. Somewhere on the server, the ID in this session cookie is stored. The server knows you are there. The server knows when you click on a link that you're the same person who generated the page on which the link was present.
When you log in, the programmer authenticates your username and password against the database (or whatever he uses for user authentication), and then stores some sort of User ID on the server, attached to your session ID from your cookie. Now, whenever you request a page, the programmer checks to see if there's a User ID associated with your session ID on the server, and then knows that you're already logged in. It's common at this point, the first thing when you log in, for there to be a bunch of select statements to load your user inforamtion, any new messages, etc. This way, it can display at the top of the page.
For example, on StackOverflow, this would be your name, reputation, amount of badges, and if you have a new message.
The website never gets confused, because the cookies are never duplicated. Whenever someone comes to the website without a cookie, a new value is generated and sent to the user in the response. Then, every request after that, the browser sends the cookie value back with it. There's no way to possibly know (and it would be nearly impossible to guess) any other user's cookie ID, assuming the server wasn't also using IP address to validate session cookies. Regardless, for the programmers, this all takes place "behind the scenes". Programmers just typically access some sort of session data repository where they can store and retrieve information that is valid across page loads. As long as the user doesn't clear his cache or restart his browser, the session data will be available and unique to that user.

It depends on the underlying technology used to create the website. Usually there's a cookie stored in your browser once you log in that uniquely identifies you. Then when you load a page, the site checks the value of the cookie to see how you are and loads information appropriate to you from a database.
As an example, when you log in to Facebook it creates a cookie on your computer. Then when you go to your homepage it knows who you are based on that cookie and uses it to load your profile picture, your friends, your apps, etc.
No switch statements, though. :O

When ever we log in to our accounts, a session or cookie is created by the server. This session or cookie contains all the relevant information that the server needs to identify the user. Once server access this info, it knows which user it is dealing with and hence retrieves the users details only.

How do I prevent unauthorized users from deleting objects in my domain model?

I got similar domain model
1) User. Every user got many cities. #OneToMany(targetEntity=adv.domain.City.class...)
2) City. Every city got many districts #OneToMany(targetEntity=adv.domain.Distinct.class)
3) Distintc
My goal is to delete distinct when user press delete button in browser. After that controller get id of distinct and pass it to bussiness layer. Where method DistinctService.deleteDistinct(Long distinctId) should delegate deliting to
DAO layer.
So my question is where to put security restrictions and what is the best way to accomplish it. I want to be sure that i delete distinct of the real user, that is the real owner of city, and city is the real owner of distinct.
So nobody exept the owner can't delete ditinct using simple url like localhost/deleteDistinct/5.
I can get user from httpSession in my controller and pass it to bussiness layer.
After that i can get all cities of this user and itrate over them to be sure, that of the citie.id == distinct.city_id and then delete distinct.
But it's rather ridiculous in my opinion.
Also i can write sql query like this ...
delete from
t_distinct
where
t_distinct.city_id in (
select
t_city.id
from
t_city
left join t_user on t_user.id = t_city.owner_id
where
t_user.id = ?
)
and t_distinct.id = ?
So what is the best practice to add restrictions like this.
I'm using Hibernate, Spring, Spring MVC by the way..
Thank you

What you're asking for is not SQL Injection prevention. You need to ensure the user attempting the deletion is authorized.
As long as you check that the user accessing the page has the rights to delete the row your trying to delete (this would be checked in the Business layer), and ONLY allow the delete command if the user is authenticated and authorized to perform the action.

With hibernate you don't have to worry about sql injection. It always uses prepared statements, so you are safe.
As for your concrete case, this is not an sql injection. But to prevent it, make validation in the controller - whether the currently logged user owns the desired ID.
Depending on the size of the application, you can implement some general security scheme, with ownership settings, and apply it (using AOP).

I understand that i want to be sure, the the user is real owner of Book The question was how to accomplish it. And yes, i know that user is authenticated and authorized. But another authorized user can easy delete pages of another user.
This can be done like this...
User userFromHttpSession ...
Long bookId = load page, get bookId, load book, get bookId
List books = userFromHttpSession.getBooks();
... iterate over books and find out if one of the book.id == bookId
... then if book owner is owner of httpSession, then proceed Delete
It's like too many sql queries, and too many code, probably there are better solution. Anyway thank you for your answers

Just use your head, quote-escape* everything from an outside (or inside for that matter) source before it gets put in an SQL statement, and check data as it goes in. Or, use prepared statements.
*Edit: By "quote-escape" I meant functions like PHP's mysql_escape_string()

How do I keep a user logged into my site for months?

I'm using OpenID. How do I make it so that the user stays logged in for a long time even after closing the browser window?
How do I store and get access to the user's User object?
Basically, I guess I just don't really understand how sessions work in Java.

So you actually want like a "Remember me on this computer" option? This is actually unrelated to OpenID part. Here's a language-agnostic way how you can do it:
First create a DB table with at least cookie_id and user_id columns. If necessary also add a cookie_ttl and ip_lock. The column names speaks for itself I guess.
On first-time login (if necessary only with the "Remember me" option checked), generate a long, unique, hard-to-guess key (which is in no way related to the user) which represents the cookie_id and store this in the DB along with the user_id. Store the cookie_id as cookie value of a cookie with known cookie name, e.g. remember. Give the cookie a long lifetime, e.g. one year.
On every request, check if the user is logged in. If not, then check the cookie value cookie_id associated with the cookie name remember. If it is there and it is valid according the DB, then automagically login the user associated with the user_id and postpone the cookie age again and if any, also the cookie_ttl in DB.
In Java/JSP/Servlet terms, make use of HttpServletResponse#addCookie() to add a cookie and HttpServletRequest#getCookies() to get cookies. You can do all the first-time checking in a Filter which listens on the desired recources, e.g. /* or maybe a bit more restricted.
With regard to sessions, you don't need it here. It has a shorter lifetime than you need. Only use it to put the logged-in user or the "found" user when it has a valid remember cookie. This way the Filter can just check its presence in the session and then don't need to check the cookies everytime.
It's after all fairly straight forward. Good luck.
See also:
How to implement "Stay Logged In" when user login in to the web application
How do servlets work? Instantiation, sessions, shared variables and multithreading

Well, the original reason I chose OpenID was so someone else could handle as much of the implementation and security of authentication for me.
After looking into OpenID more, it appears there is something called an "Immediate Request" (http://openid.net/specs/openid-authentication-2_0.html#anchor28).
When requesting authentication, the Relying Party MAY request that the OP not interact with the end user. In this case the OP MUST respond immediately with either an assertion that authentication is successful, or a response indicating that the request cannot be completed without further user interaction.
Because of this I think I could just store the user's openID url in the cookie, and use an immediate request to see if the user is authenticated or not. This way I don't have to do anything with my database, or implement any logic for preventing session hijacking of the long-lived cookie.
This method of doing it seems to be the way OpenID suggests to do it with their Relying Party Best Practices document.