You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rampart-dev@ws.apache.org by "Abdelaziz Samari (JIRA)" <ji...@apache.org> on 2007/06/27 18:00:28 UTC

[jira] Created: (RAMPART-50) parameter ttl not evaluated org.apache.rampart.handler.WSDoAllReceiver.processBasic

parameter ttl not evaluated org.apache.rampart.handler.WSDoAllReceiver.processBasic
-----------------------------------------------------------------------------------

                 Key: RAMPART-50
                 URL: https://issues.apache.org/jira/browse/RAMPART-50
             Project: Rampart
          Issue Type: Bug
          Components: rampart-core
    Affects Versions: 1.1
            Reporter: Abdelaziz Samari


In the method processBasic of the org.apache.rampart.handler.WSDoAllReceiver the followed code seems to be buggy

 				/*
         * Perform further checks on the timestamp that was transmitted in the
         * header. In the following implementation the timestamp is valid if it
         * was created after (now-ttl), where ttl is set on server side, not by
         * the client.
         * 
         * Note: the method verifyTimestamp(Timestamp) allows custom
         * implementations with other validation algorithms for subclasses.
         */

        // Extract the timestamp action result from the action vector
        actionResult = WSSecurityUtil.fetchActionResult(wsResult,
                WSConstants.TS);

        if (actionResult != null) {
            Timestamp timestamp = actionResult.getTimestamp();

            if (timestamp != null) {
                String ttl = null;
                if ((ttl = (String) getOption(WSHandlerConstants.TTL_TIMESTAMP)) == null) {
                    ttl = (String) getProperty(msgContext,
                            WSHandlerConstants.TTL_TIMESTAMP);
                }
                int ttl_i = 0;
                if (ttl != null) {
                    try {
                        ttl_i = Integer.parseInt(ttl);
                    } catch (NumberFormatException e) {
                        ttl_i = reqData.getTimeToLive();
                    }
                }
                if (ttl_i <= 0) {
                    ttl_i = reqData.getTimeToLive();
                }

                if (!verifyTimestamp(timestamp, reqData.getTimeToLive())) {
                    throw new AxisFault(
                            "WSDoAllReceiver: The timestamp could not be validated");
                }
            }
        }
        
The parameter ttl is read (getOption rsp. getProperty) but not used to call the methode verifyTimestamp. 
The correct call is :

		if (!verifyTimestamp(timestamp, ttl_i)) {
                    throw new AxisFault(
                            "WSDoAllReceiver: The timestamp could not be validated");
                }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (RAMPART-50) parameter ttl not evaluated org.apache.rampart.handler.WSDoAllReceiver.processBasic

Posted by "Ruchith Udayanga Fernando (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/RAMPART-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ruchith Udayanga Fernando resolved RAMPART-50.
----------------------------------------------

    Resolution: Fixed

Fixed :
http://svn.apache.org/viewvc?view=rev&rev=563721

Thanks,
Ruchith

> parameter ttl not evaluated org.apache.rampart.handler.WSDoAllReceiver.processBasic
> -----------------------------------------------------------------------------------
>
>                 Key: RAMPART-50
>                 URL: https://issues.apache.org/jira/browse/RAMPART-50
>             Project: Rampart
>          Issue Type: Bug
>          Components: rampart-core
>    Affects Versions: 1.1
>            Reporter: Abdelaziz Samari
>
> In the method processBasic of the org.apache.rampart.handler.WSDoAllReceiver the followed code seems to be buggy
>  				/*
>          * Perform further checks on the timestamp that was transmitted in the
>          * header. In the following implementation the timestamp is valid if it
>          * was created after (now-ttl), where ttl is set on server side, not by
>          * the client.
>          * 
>          * Note: the method verifyTimestamp(Timestamp) allows custom
>          * implementations with other validation algorithms for subclasses.
>          */
>         // Extract the timestamp action result from the action vector
>         actionResult = WSSecurityUtil.fetchActionResult(wsResult,
>                 WSConstants.TS);
>         if (actionResult != null) {
>             Timestamp timestamp = actionResult.getTimestamp();
>             if (timestamp != null) {
>                 String ttl = null;
>                 if ((ttl = (String) getOption(WSHandlerConstants.TTL_TIMESTAMP)) == null) {
>                     ttl = (String) getProperty(msgContext,
>                             WSHandlerConstants.TTL_TIMESTAMP);
>                 }
>                 int ttl_i = 0;
>                 if (ttl != null) {
>                     try {
>                         ttl_i = Integer.parseInt(ttl);
>                     } catch (NumberFormatException e) {
>                         ttl_i = reqData.getTimeToLive();
>                     }
>                 }
>                 if (ttl_i <= 0) {
>                     ttl_i = reqData.getTimeToLive();
>                 }
>                 if (!verifyTimestamp(timestamp, reqData.getTimeToLive())) {
>                     throw new AxisFault(
>                             "WSDoAllReceiver: The timestamp could not be validated");
>                 }
>             }
>         }
>         
> The parameter ttl is read (getOption rsp. getProperty) but not used to call the methode verifyTimestamp. 
> The correct call is :
> 		if (!verifyTimestamp(timestamp, ttl_i)) {
>                     throw new AxisFault(
>                             "WSDoAllReceiver: The timestamp could not be validated");
>                 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.