Form based security in WebLogic 7.0 - back button quirk

I have an application comprised of several JSPs that are protected via Form based
security and enforce an SSL connection via the appropriate declarations in the
web.xml. This aspect of the application seems to be working with the exception
of one small quirk.
If a user presses that back button until such time as the receive the container
provided login page once again, and subsequently provide a valid user id and password,
they are NOT successfully logged in. Rather, they receive the ugly 403 Forbidden
error that states that the server understood the request, but is refusing to fufill
it. This only seems to happen given the above course of events involving the
use of a back button in the browser (or selection of an item from the history
list). I suspect that this has something to do with the session id being cached
or something, but I'm not sure? Can anyone offer any assistance on this one?
Also, does anyone know of a way of preventing the user from bookmarking this container
provided login page as this also seems to be causing problems for users. If they
bookmark the first protected page of the application all is fine, but if they
bookmark the login page they receive the 403 error.
Thanks in advance!

The cure for the symtops described below was to simply add a welcome-file-list
element with appropriate welcome pages to the web.xml descriptor. It makes sense
now that I have worked it out.
Todd
"Todd Gould" <[email protected]> wrote:
>
I have an application comprised of several JSPs that are protected via
Form based
security and enforce an SSL connection via the appropriate declarations
in the
web.xml. This aspect of the application seems to be working with the
exception
of one small quirk.
If a user presses that back button until such time as the receive the
container
provided login page once again, and subsequently provide a valid user
id and password,
they are NOT successfully logged in. Rather, they receive the ugly 403
Forbidden
error that states that the server understood the request, but is refusing
to fufill
it. This only seems to happen given the above course of events involving
the
use of a back button in the browser (or selection of an item from the
history
list). I suspect that this has something to do with the session id being
cached
or something, but I'm not sure? Can anyone offer any assistance on this
one?
Also, does anyone know of a way of preventing the user from bookmarking
this container
provided login page as this also seems to be causing problems for users.
If they
bookmark the first protected page of the application all is fine, but
if they
bookmark the login page they receive the 403 error.
Thanks in advance!

Similar Messages

  • Form based security in WebLogic 7.0

    I'm sorry for the beginner level question, but I seem to be missing a critical step
    in getting Form based security to work. I have a Web application comprised of several
    JSPs. I want to attache simple FORM based security contrainsts to all pages in the
    app. Here are the exceprts from my web.xml:
    <security-constraint>
    <web-resource-collection>
    <web-resource-name>DTSTAT</web-resource-name>
    <url-pattern>/StateServlet/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
    <role-name>Sysops</role-name>
    </auth-constraint>
    <user-data-constraint>
    <transport-guarantee>NONE</transport-guarantee>
    </user-data-constraint>
    </security-constraint>
    <login-config>
    <auth-method>FORM</auth-method>
    <form-login-config>
    <form-login-page>/StateServlet/login.html</form-login-page>
    <form-error-page>/StateServlet/login-error.html</form-error-page>
    </form-login-config>
    </login-config>
    <security-role>
    <role-name>Sysops</role-name>
    </security-role>
    The app deploys correctly and I have verified that the constrinsts, etc. are recognized
    by WebLogic by inspecting the content displayed from the Admin console under the
    "Edit Web Apllication Deployment Descriptor" link - all looks as I had expected and
    matches the XML configuration above.
    I then use the "Define Resources and Roles for Web Resource Collections" link. Under
    the "Define Policies" section I see the constraints as defined above. I then use
    the "Define Roles" link to define the "Sysops" role for this application and add
    the condition "Caller is a member of the group" and use Administrators as the Group.
    From this point, I invoke one of the JSPS in the app and presented with the Login
    page as expected. However, no matter what I enter for user and password, I always
    get the login-error page back. I'm purposely trying to keep this simple so that
    I can use the system user as a test case (who is a member of the Administartors group).
    However, I have also created an additional separate user and added them to the Administartors
    group as well with the same unsuccessful results.
    Can anyone help me out please? I've been reading the docs and seem to be missing
    a key element somewhere.
    Thanks in advance,
    Todd

              Try to refer to the documentation for
              Configuring Security in Web Applications at
              http://e-docs.bea.com/wls/docs70///webapp/security.html
              Does the weblogic.log file contain any error or warning
              messages corresponding to your problem ?
              If you have a test case to reproduce the problem, you
              can contact BEA support at [email protected]
              Thanks
              Developer Relations Engineer
              

  • Using container managed form-based security in JSF

    h1. Using container managed, form-based security in a JSF web app.
    A Practical Solution
    h2. {color:#993300}*But first, some background on the problem*{color}
    The Form components available in JSF will not let you specify the target action, everything is a post-back. When using container security, however, you have to specifically submit to the magic action j_security_check to trigger authentication. This means that the only way to do this in a JSF page is to use an HTML form tag enclosed in verbatim tags. This has the side effect that the post is not handled by JSF at all meaning you can't take advantage of normal JSF functionality such as validators, plus you have a horrible chimera of a page containing both markup and components. This screws up things like skinning. ([credit to Duncan Mills in this 2 years old article|http://groundside.com/blog/DuncanMills.php?title=j2ee_security_a_jsf_based_login_form&more=1&c=1&tb=1&pb=1]).
    In this solution, I will use a pure JSF page as the login page that the end user interacts with. This page will simply gather the input for the username and password and pass that on to a plain old jsp proxy to do the actual submit. This will avoid the whole problem of having to use verbatim tags or a mixture of JSF and JSP in the user view.
    h2. {color:#993300}*Step 1: Configure the Security Realm in the Web App Container*{color}
    What is a container? A container is basically a security framework that is implemented directly by whatever app server you are running, in my case Glassfish v2ur2 that comes with Netbeans 6.1. Your container can have multiple security realms. Each realm manages a definition of the security "*principles*" that are defined to interact with your application. A security principle is basically just a user of the system that is defined by three fields:
    - Username
    - Group
    - Password
    The security realm can be set up to authenticate using a simple file, or through JDBC, or LDAP, and more. In my case, I am using a "file" based realm. The users are statically defined directly through the app server interface. Here's how to do it (on Glassfish):
    1. Start up your app server and log into the admin interface (http://localhost:4848)
    2. Drill down into Configuration > Security > Realms.
    3. Here you will see the default realms defined on the server. Drill down into the file realm.
    4. There is no need to change any of the default settings. Click the Manage Users button.
    5. Create a new user by entering username/password.
    Note: If you enter a group name then you will be able to define permissions based on group in your app, which is much more usefull in a real app.
    I entered a group named "Users" since my app will only have one set of permissions and all users should be authenticated and treated the same.
    That way I will be able to set permissions to resources for the "Users" group that will apply to all users that have this group assigned.
    TIP: After you get everything working, you can hook it all up to JDBC instead of "file" so that you can manage your users in a database.
    h2. {color:#993300}*Step 2: Create the project*{color}
    Since I'm a newbie to JSF, I am using Netbeans 6.1 so that I can play around with all of the fancy Visual Web JavaServer Faces components and the visual designer.
    1. Start by creating a new Visual Web JSF project.
    2. Next, create a new subfolder under your web root called "secure". This is the folder that we will define a Security Constraint for in a later step, so that any user trying to access any page in this folder will be redirected to a login page to sign in, if they haven't already.
    h2. {color:#993300}*Step 3: Create the JSF and JSP files*{color}
    In my very simple project I have 3 pages set up. Create the following files using the default templates in Netbeans 6.1:
    1. login.jsp (A Visual Web JSF file)
    2. loginproxy.jspx (A plain JSPX file)
    3. secure/securepage.jsp (A Visual Web JSF file... Note that it is in the sub-folder named secure)
    Code follows for each of the files:
    h3. {color:#ff6600}*First we need to add a navigation rule to faces-config.xml:*{color}
        <navigation-rule>
    <from-view-id>/login.jsp</from-view-id>
            <navigation-case>
    <from-outcome>loginproxy</from-outcome>
    <to-view-id>/loginproxy.jspx</to-view-id>
            </navigation-case>
        </navigation-rule>
    NOTE: This navigation rule simply forwards the request to loginproxy.jspx whenever the user clicks the submit button. The button1_action() method below returns the "loginproxy" case to make this happen.
    h3. {color:#ff6600}*login.jsp -- A very simple Visual Web JSF file with two input fields and a button:*{color}
    <?xml version="1.0" encoding="UTF-8"?>
    <jsp:root version="2.1"
    xmlns:f="http://java.sun.com/jsf/core"
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:jsp="http://java.sun.com/JSP/Page"
    xmlns:webuijsf="http://www.sun.com/webui/webuijsf">
        <jsp:directive.page
    contentType="text/html;charset=UTF-8"
    pageEncoding="UTF-8"/>
        <f:view>
            <webuijsf:page
    id="page1">
    <webuijsf:html id="html1">
    <webuijsf:head id="head1">
    <webuijsf:link id="link1"
    url="/resources/stylesheet.css"/>
    </webuijsf:head>
    <webuijsf:body id="body1" style="-rave-layout: grid">
    <webuijsf:form id="form1">
    <webuijsf:textField binding="#{login.username}"
    id="username" style="position: absolute; left: 216px; top:
    96px"/>
    <webuijsf:passwordField binding="#{login.password}" id="password"
    style="left: 216px; top: 144px; position: absolute"/>
    <webuijsf:button actionExpression="#{login.button1_action}"
    id="button1" style="position: absolute; left: 216px; top:
    216px" text="GO"/>
    </webuijsf:form>
    </webuijsf:body>
    </webuijsf:html>
            </webuijsf:page>
        </f:view>
    </jsp:root>h3. *login.java -- implent the
    button1_action() method in the login.java backing bean*
        public String button1_action() {
            setValue("#{requestScope.username}",
    (String)username.getValue());
    setValue("#{requestScope.password}", (String)password.getValue());
            return "loginproxy";
        }h3. {color:#ff6600}*loginproxy.jspx -- a login proxy that the user never sees. The onload="document.forms[0].submit()" automatically submits the form as soon as it is rendered in the browser.*{color}
    {code}
    <?xml version="1.0" encoding="UTF-8"?>
    <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page"
    version="2.0">
    <jsp:output omit-xml-declaration="true" doctype-root-element="HTML"
    doctype-system="http://www.w3.org/TR/html4/loose.dtd"
    doctype-public="-W3CDTD HTML 4.01 Transitional//EN"/>
    <jsp:directive.page contentType="text/html"
    pageEncoding="UTF-8"/>
    <html>
    <head> <meta
    http-equiv="Content-Type" content="text/html;
    charset=UTF-8"/>
    <title>Logging in...</title>
    </head>
    <body
    onload="document.forms[0].submit()">
    <form
    action="j_security_check" method="POST">
    <input type="hidden" name="j_username"
    value="${requestScope.username}" />
    <input type="hidden" name="j_password"
    value="${requestScope.password}" />
    </form>
    </body>
    </html>
    </jsp:root>
    {code}
    h3. {color:#ff6600}*secure/securepage.jsp -- A simple JSF{color}
    target page, placed in the secure folder to test access*
    {code}
    <?xml version="1.0" encoding="UTF-8"?>
    <jsp:root version="2.1"
    xmlns:f="http://java.sun.com/jsf/core"
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:webuijsf="http://www.sun.com/webui/webuijsf">
    <jsp:directive.page
    contentType="text/html;charset=UTF-8"
    pageEncoding="UTF-8"/>
    <f:view>
    <webuijsf:page
    id="page1">
    <webuijsf:html id="html1">
    <webuijsf:head id="head1">
    <webuijsf:link id="link1"
    url="/resources/stylesheet.css"/>
    </webuijsf:head>
    <webuijsf:body id="body1" style="-rave-layout: grid">
    <webuijsf:form id="form1">
    <webuijsf:staticText id="staticText1" style="position:
    absolute; left: 168px; top: 144px" text="A Secure Page"/>
    </webuijsf:form>
    </webuijsf:body>
    </webuijsf:html>
    </webuijsf:page>
    </f:view>
    </jsp:root>
    {code}
    h2. {color:#993300}*_Step 4: Configure Declarative Security_*{color}
    This type of security is called +declarative+ because it is not configured programatically. It is configured by declaring all of the relevant parameters in the configuration files: *web.xml* and *sun-web.xml*. Once you have it configured, the container (application server and java framework) already have the implementation to make everything work for you.
    *web.xml will be used to define:*
    - Type of security - We will be using "form based". The loginpage.jsp we created will be set as both the login and error page.
    - Security Roles - The security role defined here will be mapped (in sun-web.xml) to users or groups.
    - Security Constraints - A security constraint defines the resource(s) that is being secured, and which Roles are able to authenticate to them.
    *sun-web.xml will be used to define:*
    - This is where you map a Role to the Users or Groups that are allowed to use it.
    +I know this is confusing the first time, but basically it works like this:+
    *Security Constraint for a URL* -> mapped to -> *Role* -> mapped to -> *Users & Groups*
    h3. {color:#ff6600}*web.xml -- here's the relevant section:*{color}
    {code}
    <security-constraint>
    <display-name>SecurityConstraint</display-name>
    <web-resource-collection>
    <web-resource-name>SecurePages</web-resource-name>
    <description/>
    <url-pattern>/faces/secure/*</url-pattern>
    <http-method>GET</http-method>
    <http-method>POST</http-method>
    <http-method>HEAD</http-method>
    <http-method>PUT</http-method>
    <http-method>OPTIONS</http-method>
    <http-method>TRACE</http-method>
    <http-method>DELETE</http-method>
    </web-resource-collection>
    <auth-constraint>
    <description/>
    <role-name>User</role-name>
    </auth-constraint>
    </security-constraint>
    <login-config>
    <auth-method>FORM</auth-method>
    <realm-name/>
    <form-login-config>
    <form-login-page>/faces/login.jsp</form-login-page>
    <form-error-page>/faces/login.jsp</form-error-page>
    </form-login-config>
    </login-config>
    <security-role>
    <description/>
    <role-name>User</role-name>
    </security-role>
    {code}
    h3. {color:#ff6600}*sun-web.xml -- here's the relevant section:*{color}
    {code}
    <security-role-mapping>
    <role-name>User</role-name>
    <group-name>Users</group-name>
    </security-role-mapping>
    {code}
    h3. {color:#ff6600}*Almost done!!!*{color}
    h2. {color:#993300}*_Step 5: A couple of minor "Gotcha's"_ *{color}
    h3. {color:#ff6600}*_Gotcha #1_*{color}
    You need to configure the "welcome page" in web.xml to point to faces/secure/securepage.jsp ... Note that there is *_no_* leading / ... If you put a / in there it will barf all over itself .
    h3. {color:#ff6600}*_Gotcha #2_*{color}
    Note that we set the <form-login-page> in web.xml to /faces/login.jsp ... Note the leading / ... This time, you NEED the leading slash, or the server will gag.
    *DONE!!!*
    h2. {color:#993300}*_Here's how it works:_*{color}
    1. The user requests the a page from your context (http://localhost/MyLogin/)
    2. The servlet forwards the request to the welcome page: faces/secure/securepage.jsp
    3. faces/secure/securepage.jsp has a security constraint defined, so the servlet checks to see if the user is authenticated for the session.
    4. Of course the user is not authenticated since this is the first request, so the servlet forwards the request to the login page we configured in web.xml (/faces/login.jsp).
    5. The user enters username and password and clicks a button to submit.
    6. The button's action method stores away the username and password in the request scope.
    7. The button returns "loginproxy" navigation case which tells the navigation handler to forward the request to loginproxy.jspx
    8. loginproxy.jspx renders a blank page to the user which has hidden username and password fields.
    9. The hidden username and password fields grab the username and password variables from the request scope.
    10. The loginproxy page is automatically submitted with the magic action "j_security_check"
    11. j_security_check notifies the container that authentication needs to be intercepted and handled.
    12. The container authenticates the user credentials.
    13. If the credentials fail, the container forwards the request to the login.jsp page.
    14. If the credentials pass, the container forwards the request to *+the last protected resource that was attempted.+*
    +Note the last point! I don't know how, but no matter how many times you fail authentication, the container remembers the last page that triggered authentication and once you finally succeed the container forwards your request there!!!!+
    +The user is now at the secure welcome page.+
    If you have read this far, I thank you for your time, and I seriously question your ability to ration your time pragmatically.
    Kerry Randolph

    If you want login security on your web app, this is one way to do it. (the easiest way i have seen).
    This method allows you to create a custom login form and error page using JSF.
    The container handles the actual authentication and protection of the resources based on what you declare in web.xml and sun-web.xml.
    This example uses a statically defined user/password, stored in a file, but you can also configure JDBC realm in Glassfish, so that that users can register for access and your program can store the username/passwrod in a database.
    I'm new to programming, so none of this may be a good practice, or may not be secure at all.
    I really don't know what I'm doing, but I'm learning, and this has been the easiest way that I have found to add authentication to a web app, without having to write the login modules yourself.
    Another benefit, and I think this is key ***You don't have to include any extra code in the pages that you want to protect*** The container manages this for you, based on the constraints you declare in web.xml.
    So basically you set it up to protect certain folders, then when any user tries to access pages in that folder, they are required to authenticate.
    --Kerry                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • Adding an External Application that uses J2EE Form Based Security

    I'm trying to add an External application that uses the J2EE Form based security. i.e. uses j_username, j_password and posts to j_security_check.
    I don't really see how Oracle SSO will support this. The container needs to take control of a clients request and determines when the "Login" page is presented to establish credentials. Posting directly to j_security_check isn't working for me.
    I'm using Sybase EAServer 4.12 as the external application.
    Is this supported in Oracle SSO?
    Do I need to provide a different mechanism for logging user's in?
    Also, can someone explain what the benefit would be if I configured the EAServer app as a "Partner" app? I would still have to provide an interface for login. The input would be different but the end result would be the same I guess. What advantages does a Partner app have?
    Lastly, is there an NNTP server for these forums?
    Thanks.
    Darrell

    The cure for the symtops described below was to simply add a welcome-file-list
    element with appropriate welcome pages to the web.xml descriptor. It makes sense
    now that I have worked it out.
    Todd
    "Todd Gould" <[email protected]> wrote:
    >
    I have an application comprised of several JSPs that are protected via
    Form based
    security and enforce an SSL connection via the appropriate declarations
    in the
    web.xml. This aspect of the application seems to be working with the
    exception
    of one small quirk.
    If a user presses that back button until such time as the receive the
    container
    provided login page once again, and subsequently provide a valid user
    id and password,
    they are NOT successfully logged in. Rather, they receive the ugly 403
    Forbidden
    error that states that the server understood the request, but is refusing
    to fufill
    it. This only seems to happen given the above course of events involving
    the
    use of a back button in the browser (or selection of an item from the
    history
    list). I suspect that this has something to do with the session id being
    cached
    or something, but I'm not sure? Can anyone offer any assistance on this
    one?
    Also, does anyone know of a way of preventing the user from bookmarking
    this container
    provided login page as this also seems to be causing problems for users.
    If they
    bookmark the first protected page of the application all is fine, but
    if they
    bookmark the login page they receive the 403 error.
    Thanks in advance!

  • Form-Based Security

    I cannot seem to get container-managed security to work with Java Studio Creator.
    I have a standard jsp page as the logon form, submitting to j_security_check. Authentication works correctly, but then, when the protected page is rendered, I keep getting the "Faces Context cannot be found" exception. Is this because I have a non-faces page between two faces pages?
    Here are the steps:
    1). Access the main page
    2). Main faces page gets rendered correctly.
    3). Access a link which sends the user to a protected page
    4). Logon page gets rendered. (plain JSP or HTML file)
    All is well so far
    5). User credentials are submitted
    6). Authentication works correctly
    7). Forward user to the protected faces page
    8). "Cannot find Faces Context" exception.
    Obviously, I cannot create a "standard" jsp page in Creator, as Creator creates the faces context and the java backend automatically. I had to create the JSP page through a text editor, and save it to the Creator project directory.
    The same thing happens if I create a regular HTML file in Creator with the same form submitting to j_security_check.
    Anyone run into this? Has anyone gotten container-managed, forms-based security working with Creator?
    Thanks.

    Ummmm.... okay, I feel really foolish and stupid. I guess I was getting tunnel vision, staring at this project so much.
    Sheesh! Thanks for the reply, j.f.brown! Had you not made the reply, who knows how long I would have stared at this problem.
    I'm never going to live this down. heh heh.

  • WebLogic Form-based security

    I am using form-based login to authenticate users. I want to tie all entry points
    on successful login to a single page. Is there a way to accomplish this? In the
    web.xml one can configure the error page to be forwarded to on login failure but
    there is nothing on these lines for successful logins i.e. page to be forwarded to
    login success.
    <form-login-config>
    <form-login-page> login.jsp</<form-login-page>
    <form-error-page>error.jsp</<form-error-page>
    </form-login-config>
    Any ideas on how to accomplish this?
    Sanjay

    on login.jsp page do some jsp code that changes the j_target_url to the URL that you
    want all users to be directed to
    Cheers
    Joe Jerry
    I am using form-based login to authenticate users. I want to tie all entry points
    on successful login to a single page. Is there a way to accomplish this? In the
    web.xml one can configure the error page to be forwarded to on login failure but
    there is nothing on these lines for successful logins i.e. page to be forwarded to
    login success.
    <form-login-config>
    <form-login-page> login.jsp</<form-login-page>
    <form-error-page>error.jsp</<form-error-page>
    </form-login-config>
    Any ideas on how to accomplish this?
    Sanjay

  • Error in Role Based security using weblogic 9

    Hi All,
    Currently I am working with Weblogic Server 9. I am trying to use role based security. Below is the entries for web.xml.
    <security-constraint>
         <web-resource-collection>
              <web-resource-name>Success</web-resource-name>
              <url-pattern>/form.jsp</url-pattern>
              <http-method>GET</http-method>
              <http-method>POST</http-method>
         </web-resource-collection>
         <auth-constraint>
              <role-name>admin</role-name>
         </auth-constraint>
         <user-data-constraint>
    <transport-guarantee>INTEGRAL</transport-guarantee>
    </user-data-constraint>
    </security-constraint>
    <login-config>
         <auth-method>BASIC</auth-method>
         <realm-name>myrealm</realm-name>
    </login-config>
    <security-role>
         <role-name>admin</role-name>
    </security-role>
    When I am calling form.jsp from the browser it is asking for the username and password, but after giving the username and password it is showing the followig error:
    Error 403--Forbidden
    From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
    10.4.4 403 Forbidden
    The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
    So can any one provide me the solution for the above problem.
    Thanks in advance.
    By,
    Sandip Pradhan

    Here is a blog post for the backend (WebLogic Admin GUI) http://disaak.blogspot.com/2009/11/migrating-to-weblogic-configure-role.html and a blog post for the web.xml in your project http://disaak.blogspot.com/2009/11/migrating-to-weblogic-configure-ear.html.

  • Securing Portal when hitting the Back Button

    Does Portal have the ability to support kiosks operation (not
    able to press back button to reveal sensitive information) while
    in session?

    If this does turn out to be a fault with firefox you will need to file a bug to investigate it. Meanwhile you will probably be able to get knowledgeable comment from one of the Mozillazine forums: http://forums.mozillazine.org/viewforum.php?f=25

  • How to trigger and change password for AD user after form based login

    Hello,
    We are authenticating against Active Directory with Weblogic 10.3 using FORM based security. Everything is working. I need to now change a password for an authenticated user. For example, I have set a user to have their password expire on next logon from the AD side. The user logs in but somehow I need to trap some info from Active Directory (or an LDAP conversation) to figure out if I need to force the user to change password.
    Do I need to start looking at custom code with LDAP Java SDK's or can I use a canned MBean from Weblogic Server.
    I am looking at http://www.mozilla.org/directory/ for LDAP.
    Can I set/reset an AD user's password with an MBean like the following link?
    http://download.oracle.com/docs/cd/E13222_01/wls/docs92/javadocs/index.html?weblogic/management/security/authentication/UserPasswordEditorMBean.html
    If anyone has any experience with this or can point me in the right direction let me know.
    If anyone else is interested please add to the tread and I'll be sure to keep the found solution(s) updated here.
    Thanks...........
    JJ Everett

    Hello JJ
    Please see document ID 403484.1 in http://metalink.oracle.com. This may help to understand what you are aiming to do. Cheers
    -- Nathan

  • Applying application security using weblogic

    Hi, I want to know a procedure of deploying a fusion application on weblogic server using ear file
    I also want to know how to apply security on the application from database like I have users and groups each user belongs to a certain group I want is to verfy the user from database and give this user access of application contents based on user group.
    I have done this on LDAP but I did not need LDAP security I want to apply security on weblogic server using back end database.
    tell me if you know the procedure

    See this - https://blogs.oracle.com/jruiz/entry/deploying_an_adf_secure_applic for creating EAR and creating configuring the server.
    Permissions would need to be given to pages and taskflows in jazn-data.xml as here - http://andrejusb.blogspot.in/2008/07/declarative-security-in-jdeveloperadf.html
    and you would need to create a Custom SQL Authenticator using http://biemond.blogspot.in/2008/12/using-database-tables-as-authentication.html and configure it in weblogic server.

  • Form based authentication HTTP 403 access forbidden in WL 8.1

    Hi there..
    I found following message posted in April-2004 by Sandeep very useful.
    I also ended up getting the following HTTP 403 Forbidden access error while using Pageflow controller and Form based authentication.
    I noticed 2 things. If you have a normal webapp A, which is a plain old webapp (which does not use pageflow..workshop etc..) then the following error does not occur.
    It only happens with those webapps which utilizes WL 8.1's pageflow features. Note that I am not using nested page flows. I just used 1 pageflow controller and wanted to have the form based login feature for the same.
    BEA's samples on form authentication talks about nested page flows and javax.security.auth.login.FailedLoginException and etc.. are they only applicable to nested pageflows?
    can't I use the same to capture failed login exception within a single controller?
    I tried out putting FailedLoginException exception-handler in Global.app file but it didn't catch it. Only the following work around worked. is this a bug in WL 8.1 workshop? or I am missing something.
    I would appreciate if someone can clear this doubt.
    I am using WL 8.1 with sp3.
    Rajesh
    Hey guys,
    I could find the solution for my problem. Here it is
    We need to add following lines of code in the erro.jsp page.
    <form action"j_security_check>
    ....write the error mesage....
    </form>
    You will get rid of "403 Forbidden page" error.
    Thanks,
    Sandip
    [email protected] (Sandip Atkole) wrote in message news:<[email protected]>...
    I am trying to set up Form-Based Authentication on WebLogic 8.1
    The Problem:
    If the user provides correct userid/password, he gets access to the
    protected resource as required, but if he provides incorrect
    userid/password, he gets a 403 Forbidden page, instead of getting the
    login failure page.
    The Descriptors:
    WEB.XML
    <login-config>
    <auth-method>FORM</auth-method>
    <form-login-config>
    <form-login-page>/Login.jsp</form-login-page>
    <form-error-page>/LoginError.jsp</form-error-page>
    </form-login-config>
    </login-config>
    Why doesn't it redirect to "/LoginError.jsp" instead of showing the
    403 Forbidden page?
    Thanks in advance
    Sandip

    It seems like a bug. However when I explicitly reset the error using set status it worked for me. I added following code in my error jsp .
    <%     
         response.setHeader("conent-type","text/html");
         response.setStatus(200);
    %>

  • Form Based Role Validation

    I am trying to use the form based security role validation. I am using JDeveloper's built in OC4J. I am getting to my login form but when I try to submit I get the following:
    java.lang.IllegalArgumentException: Resource /j_security_check?j_username=myuserhere&j_password=mypasswordhere not found
    I have the user defined in the principals.xml file I am specifying the location of the principals.xml file in the WEBAPPNAMEHERE-oc4j-app.xml file which seems to be where JDeveloper wants it.
    Any ideas?

    See section 12.5.3.1 of the Servlet 2.3 specification for details. You need to be sure your HTML file uses the j_security_check, j_username, and j_password names like this:
    <form method=POST action=j_security_check>
    <input type=text name=j_username>
    <input type=password name=j_password>
    </form>
    The method must be POST, not GET. This means that the user/pass information will not be visible in the URL that is set back to the server; it will instead be in the HTTP request body.

  • Back button to re-edit form..."Current version of data..." error?

    I've noticed a fairly common error that my users are running into. Here is the situation...
    A user navigates to a form...makes modifications...saves the form...and is redirected to another page. Then, the user clicks the browser back button to re-edit the form...saves the form and gets the following error...
    "...Current version of data in database has changed since user initiated update process...."
    I am currently running v2.0...but I was able to also duplicate the issue within v3 (online...Customer Tracker sample application).
    Is there any way to catch the error to display a custom message?
    Or maybe some settings that I am missing to guarantee that when the user clicks the back button, the page is refreshed so it doesn't show the cached version with the old data?
    Or maybe there is another way to approach this?
    Thanks...
    Matt

    Matt,
    This is functioning exactly as it should... Imagine what could happen if it didn't work that way! People would overwrite other's information all the time.
    I think the solution you need is two fold: user training and app modifications.
    I know what you're thinking, user training, hah! But it's going to help as you make more of these kinds of web apps.
    As for app modifications there are two I can think of that may help.
    1. I don't know how the users open the app but if they click on a link then you can have the popup window open without tool bars and such (but they still have the backspace on the keyboard).
    2. Add a button on the page they are redirected to after saving the form. Make the condition of the back button "If item is not null" and put PXX_ITEM_NAME in expression 1.
    Then create the item you just put in expression 1as display as text (saves state). Set the condition to never. Now go to the page with the form, and create a process that sets PXX_ITEM_NAME equal to the value of the item used as the primary key for the form. Make sure the process only fires after an update is made.
    Then when the users get to the page after making a modification they will see a "back" button.
    The last step is to create a branch that will take the user back to the form if they click the button and populates the form item for the primary key.
    Let me know if this is making any sense or not.
    Dan
    Dan

  • Change in back button behavior

    We are upgrading from ColdFusion 9 to ColdFusion 11.  We noticed a change in back button behavior.  On pages running CF 9 the back button works, but on pages running CF 11, when clicking the back button, we get a browser "confirm form resubmission" message.  Since it is the same browser, it is clearly a change in ColdFusion.  Does anyone know when the change was made?  Is there a setting that controls the behavior?
    Thank you,
    David

    We should ignore the difference in Coldfusion version for a moment. It might just be that the previous behaviour was incorrect and what you now observe, with CF11, is the correct behaviour.
    A form-resubmit warning is essential. In fact, it can even be vital in certain circumstances. It is telling you that someone, some process or some thread has attempted to resubmit a form.
    In your case, clicking the back button apparently refreshes the action page of the form. This is analogous, in business terms, to repeating an order that has already been placed. The related validation code, queries, etc. will run once again. Obviously an unwelcome situation.

  • Form-based authentication problem with weblogic

    Hi Everyone,
    The following problem related to form-based authentication
    was posted one week ago and no reponse. Can someone give it
    a shot? One more thing is added here. When I try it on J2EE
    server and do the same thing, I didn't encounter this error
    message, and I am redirected to the homeage.
    Thanks.
    -John
    I am using weblogic5.1 and RDBMSRealm as the security realm. I am having the following problem with the form-based authentication login mechanism. Does anyone have an idea what the problem is and how to solve it?
    When I login my application and logout as normal procedure, it is OK. But if I login and use the browser's BACK button to back the login page and try to login as a new user, I got the following error message,
    "Form based authentication failed. Could not find session."
    When I check the LOG file, it gives me the following message,
    "Form based authentication failed. One of the following reasons could cause it: HTTP sessions are disabled. An old session ID was stored in the browser."
    Normally, if you login and want to relogin without logout first, it supposes to direct you to the existing user session. But I don't understand why it gave me this error. I also checked my property file, it appears that the HTTP sessions are enabled as follows,
    weblogic.httpd.session.enable=true

    Hi...
    Hehe... I actually did implement the way you implement it. My login.jsp actually checks if the user is authenticated. If yes, then it will forward it to the home page. On the other hand, I used ServletAuthentication to solve the problem mentioned by Cameron where Form Authentication Failed usually occurs for the first login attempt. I'm also getting this error occasionally. Using ServletAuthentication totally eliminates the occurence of this problem.
    I'm not using j_security_check anymore. ServletAuthentication does all the works. It also uses RDBMSRealm to authenticate the user. I think the biggest disadvantage I can see when using ServletAuthentication is that the requested resource will not be returned after authentication cause the page returned after authenticating the user is actually hard coded (for my case, it's the home.jsp)
    cheers...
    Jerson
    "John Wang" <[email protected]> wrote:
    >
    Hi Jerson,
    I tried your code this weekend, it didn't work in my case. But
    I solved my specific problem other way. The idea behind my problem is that the user tries to relogin when he already logs in. Therefore, I just redirect the user into another page when he is getting the login page by htting the BACK button, rather than reauthenticate the user as the way you did.
    But, I think your idea is very helpful if it could work. Problems such multiple concurrence logins can be solved by pre-processing.
    In your new code, you solved the problem with a new approach. I am just wondering, do you still implement it with your login.jsp file? In other word, your action in login.jsp is still "Authenticate"? Where do you put the URL "j_security_check"?
    Thanks.
    -John
    "Jerson Chua" <[email protected]> wrote:
    I've solved the problem by using ServletAuthentication. So far I'm not getting the error message. One of the side effects is that it doesn't return the requested URI after authentication, it will always return the home page.
    Jerson
    package com.cyberj.catalyst.web;
    import weblogic.servlet.security.*;
    import javax.servlet.*;
    import javax.servlet.http.*;
    import java.io.*;
    public class Authenticate extends HttpServlet {
    private ServletAuthentication sa = new ServletAuthentication("j_username", "j_password");
    public void doPost(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, java.io.IOException {
    int authenticated = sa.weak(request, response);
    if (authenticated == ServletAuthentication.NEEDS_CREDENTIALS ||
    authenticated == ServletAuthentication.FAILED_AUTHENTICATION) {
    response.sendRedirect("fail_login.jsp");
    } else {
    response.sendRedirect("Home.jsp");
    public void doGet(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, java.io.IOException {
    doPost(request, response);
    "Jerson Chua" <[email protected]> wrote:
    The problem is still there even if I use page redirection. Grrr... My boss wants me to solve this problem so what are the alternatives I can do? Are there any other ways of authenticating the user? In my web tier... I'm using isUserInRole, getRemoteUser and the web tier actually connects to EJBs. If I implement my custom authentication, I wouldn't be able to use this functionalities.
    Has anyone solved this problem? I've tried the example itself and the same problem occurs.
    Jerson
    "Cameron Purdy" <[email protected]> wrote:
    Jerson,
    First try it redirected (raw) to see if that indeed is the problem ... then
    if it works you can "fix" it the way you want.
    Peace,
    Cameron Purdy
    Tangosol, Inc.
    http://www.tangosol.com
    +1.617.623.5782
    WebLogic Consulting Available
    "Jerson Chua" <[email protected]> wrote in message
    news:[email protected]...
    Hi...
    Thanks for your suggestion... I've actually thought of that solution. Butusing page redirection will expose the user's password. I'm thinking of
    another indirection where I will redirect it to another servlet but the
    password is encrypted.
    What do you think?
    thanks....
    Jerson
    "Cameron Purdy" <[email protected]> wrote:
    Maybe redirect to the current URL after killing the session to let the
    request clean itself up. I don't think that a lot of the request (such
    as
    remote user) will be affected by killing the session until the nextrequest
    comes in.
    Peace,
    Cameron Purdy
    Tangosol, Inc.
    http://www.tangosol.com
    +1.617.623.5782
    WebLogic Consulting Available
    "Jerson Chua" <[email protected]> wrote in message
    news:[email protected]...
    Hello guys...
    I've a solution but it doesn't work yet so I need your help. Because
    one
    of the reason for getting form base authentication failed is if an
    authenticated user tries to login again. For example, the one mentionedby
    John using the back button to go to the login page and when the user logsin
    again, this error occurs.
    So here's my solution
    Instead of submitting the page to j_security_check, submit it to a
    servlet
    which will check if the user is logged in or not. If yes, invalidates its
    session and forward it to j_security_check. But there's a problem in this
    solution, eventhough the session.invalidate() (which actually logs theuser
    out) is executed before forwarded to j_security_check, the user doesn't
    immediately logged out. How did I know this, because after calling
    session.invalidate, i tried calling request.RemoteUser() and it doesn't
    return null. So I'm still getting the error. What I want to ask you guyis
    how do I force logout before the j_security_check is called.
    here's the code I did which the login.jsp actually submits to
    import javax.servlet.*;
    import javax.servlet.http.*;
    import java.io.*;
    public class Authenticate extends HttpServlet {
    public void doPost(HttpServletRequest request, HttpServletResponseresponse)
    throws ServletException, java.io.IOException {
    if (request.getRemoteUser() != null) {
    HttpSession session = request.getSession(false);
    System.out.println(session.isNew());
    session.invalidate();
    Cookie[] cookies = request.getCookies();
    for (int i = 0; i < cookies.length; i++) {
    cookies.setMaxAge(0);
    getServletContext().getRequestDispatcher("/j_security_check").forward(reques
    t, response);
    public void doGet(HttpServletRequest request, HttpServletResponseresponse)
    throws ServletException, java.io.IOException {
    doPost(request, response);
    let's help each other to solve this problem. thanks.
    Jerson
    "Jerson Chua" <[email protected]> wrote:
    I thought that this problem will be solved on sp6 but to my
    disappointment, the problem is still there. I'm also using RDBMSRealm,same
    as John.
    Jerson
    "Cameron Purdy" <[email protected]> wrote:
    John,
    1. You are using a single WL instance (i.e. not clustered) on that
    NT
    box
    and doing so without a proxy (e.g. specifying http://localhost:7001),
    correct?
    2. BEA will pay more attention to the problem if you upgrade to SP6.If
    you don't have a reason NOT to (e.g. a particular regression), then
    you
    should upgrade. That will save you one go-around with support: "Hi,I
    am
    on SP5 and I have a problem.", "Upgrade to SP6 to see if that fixes
    it.
    Call back if that doesn't work."
    3. Make sure that you are not doing anything special before or after
    J_SECURITY_CHECK ... make sure that you have everything configuredand
    done
    by the book.
    4. Email BEA a bug report at [email protected] ... see what they say.
    Peace,
    Cameron Purdy
    Tangosol, Inc.
    http://www.tangosol.com
    +1.617.623.5782
    WebLogic Consulting Available
    "John Wang" <[email protected]> wrote in message
    news:[email protected]...
    Cameron,
    It seems to me that the problem I encountered is different a little
    from
    what you have, evrn though the error message is the same eventually.
    Everytime I go through, I always get that error.
    I am using weblogic5.1 and sp5 on NT4.0. Do you have any solutions
    to
    work
    around this problem? If it was a BUG as you
    pointed out, is there a way we can report it to the Weblogic
    technical support and let them take a look?
    Thnaks.
    -John
    "Cameron Purdy" <[email protected]> wrote:
    John,
    I will verify that I have seen this error now (after having read
    about it
    here for a few months) and it had the following characteristics:
    1) It was intermittent, and appeared to be self-curing
    2) It was not predictable, only seemed to occur at the first
    login
    attempt,
    and may have been timing related
    3) This was on Sun Solaris on a cluster of 2 Sparc 2xx's; the
    proxy
    was
    Apache (Stronghold)
    4) After researching the newsgroups, it appears that this "bug"
    may
    have gone away temporarily (?) in SP5 (although Jerson Chua
    <[email protected]> mentioned that he still got it in SP5)
    I was able to reproduce it most often by deleting the tmpwar and
    tmp_deployments directories while the cluster was not running,
    then
    restarting the cluster. The first login attempt would fail(roughly
    90%
    of
    the time?) and that server instance would then be ignored by the
    proxy
    for a
    while (60 seconds?) -- meaning that the proxy would send all
    traffic,
    regardless of the number of "clients", to the other server in thecluster.
    As far as I can tell, it is a bug in WebLogic, and probably has
    been
    there
    for quite a while.
    Peace,
    Cameron Purdy
    Tangosol, Inc.
    http://www.tangosol.com
    +1.617.623.5782
    WebLogic Consulting Available
    "John Wang" <[email protected]> wrote in message
    news:[email protected]...
    Hi Everyone,
    The following problem related to form-based authentication
    was posted one week ago and no reponse. Can someone give it
    a shot? One more thing is added here. When I try it on J2EE
    server and do the same thing, I didn't encounter this error
    message, and I am redirected to the homeage.
    Thanks.
    -John
    I am using weblogic5.1 and RDBMSRealm as the security realm. I
    am
    having
    the following problem with the form-based authentication login
    mechanism.
    Does anyone have an idea what the problem is and how to solve it?
    When I login my application and logout as normal procedure, it
    is
    OK.
    But
    if I login and use the browser's BACK button to back the login
    page
    and
    try
    to login as a new user, I got the following error message,
    "Form based authentication failed. Could not find session."
    When I check the LOG file, it gives me the following message,
    "Form based authentication failed. One of the following reasons
    could
    cause it: HTTP sessions are disabled. An old session ID was stored
    in
    the
    browser."
    Normally, if you login and want to relogin without logout first,
    it
    supposes to direct you to the existing user session. But I don'tunderstand
    why it gave me this error. I also checked my property file, it
    appears
    that
    the HTTP sessions are enabled as follows,
    weblogic.httpd.session.enable=true

Maybe you are looking for

  • 2014 Macbook Pro 10.9.5 not discovering my iPhone 5s iOS8

    Why is Airdrop on my new Macbook Pro 10.9.5 not discovering my iPhone 5s iOS8.0.2 Bluetooth on. On same wireless home network. Selected Airdrop to everyone on my iPhone 5s. Macbook Pro was bought in August still not discovering my iphone. Airdrop ico

  • PI: File to IDOC port is empty in R/3 system

    Hi, We send an IDOC from PI. We can see the IDOC in R/3 (WE20) but the "port" is missing under "recipient infromation", there is no character in there. The other fields are all set. Where we have to set our port? In the communication channel is nothi

  • Triggering a report program

    Hi experts,       Let me to have a scenario such as follows, I want to trigger a report program with data when an event occurs in a third party tool. In the meanwhile the third party tool should through some input, following by the input will be give

  • Manipulating live objects in the Run Time system

    A Graphic User interface exists that has GUI components say JButtons. This program cannot be edited. If the container ( say a GUI panel , where this JButton resides ) of this GUI is obtained then the components in this container can be obtained using

  • Migrating web sites to new server

    Hello all, just got a new Mac Mini Server edition with the latest Snow Leopard etc. I am migrating all my various sites from the old server which was just running standard Leopard. I am having a hard time finding where everything goes. If anyone can