Fixing issues in the sample integration.

application-manager-new
sinthuja 8 years ago
parent 3bf2f21711
commit 5ca98782fd

@ -697,6 +697,10 @@
<source>src/repository/conf/security/cipher-tool.properties</source>
<outputDirectory>${pom.artifactId}-${pom.version}/repository/conf/security</outputDirectory>
</file>
<file>
<source>src/repository/conf/security/Owasp.CsrfGuard.Carbon.properties</source>
<outputDirectory>${pom.artifactId}-${pom.version}/repository/conf/security</outputDirectory>
</file>
<!-- Copying metrics feature related files -->
<file>

@ -0,0 +1,456 @@
# The OWASP CSRFGuard Project, BSD License
# Eric Sheridan (eric@infraredsecurity.com), Copyright (c) 2011
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
#
# 1. Redistributions of source code must retain the above copyright notice,
# this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the distribution.
# 3. Neither the name of OWASP nor the names of its contributors may be used
# to endorse or promote products derived from this software without specific
# prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
# (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
# LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
# ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
# SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
# From: https://github.com/esheri3/OWASP-CSRFGuard/blob/master/csrfguard-test/src/main/webapp/WEB-INF/csrfguard.properties
# Common substitutions
# %servletContext% is the servlet context (e.g. the configured app prefix or war file name, or blank.
# e.g. if you deploy a default warfile as someApp.war, then %servletContext% will be /someApp
# if there isnt a context it will be the empty string. So to use this in the configuration, use e.g. %servletContext%/something.html
# which will translate to e.g. /someApp/something.html
# Logger
#
# The logger property (org.owasp.csrfguard.Logger) defines the qualified class name of
# the object responsible for processing all log messages produced by CSRFGuard. The default
# CSRFGuard logger is org.owasp.csrfguard.log.ConsoleLogger. This class logs all messages
# to System.out which JavaEE application servers redirect to a vendor specific log file.
# Developers can customize the logging behavior of CSRFGuard by implementing the
# org.owasp.csrfguard.log.ILogger interface and setting the logger property to the new
# logger's qualified class name. The following configuration snippet instructs OWASP CSRFGuard
# to capture all log messages to the console:
#
# org.owasp.csrfguard.Logger=org.owasp.csrfguard.log.ConsoleLogger
org.owasp.csrfguard.Logger=org.owasp.csrfguard.log.JavaLogger
# Which configuration provider factory you want to use. The default is org.owasp.csrfguard.config.PropertiesConfigurationProviderFactory
# Another configuration provider has more features including config overlays: org.owasp.csrfguard.config.overlay.ConfigurationOverlayProviderFactory
# The default configuration provider is: org.owasp.csrfguard.config.overlay.ConfigurationAutodetectProviderFactory
# which will look for an overlay file, it is there, and the factory inside that file is set it will use it, otherwise will be PropertiesConfigurationProviderFactory
# it needs to implement org.owasp.csrfguard.config.ConfigurationProviderFactory
org.owasp.csrfguard.configuration.provider.factory = org.owasp.csrfguard.config.overlay.ConfigurationAutodetectProviderFactory
# If csrfguard filter is enabled
org.owasp.csrfguard.Enabled = true
# If csrf guard filter should check even if there is no session for the user
# Note: this changed around 2014/04, the default behavior used to be to
# not check if there is no session. If you want the legacy behavior (if your app
# is not susceptible to CSRF if the user has no session), set this to false
org.owasp.csrfguard.ValidateWhenNoSessionExists = true
# New Token Landing Page
#
# The new token landing page property (org.owasp.csrfguard.NewTokenLandingPage) defines where
# to send a user if the token is being generated for the first time, and the use new token landing
# page boolean property (org.owasp.csrfguard.UseNewTokenLandingPage) determines if any redirect happens.
# UseNewTokenLandingPage defaults to false if NewTokenLandingPage is not specified, and to true
# if it is specified.. If UseNewTokenLandingPage is set true then this request is generated
# using auto-posting forms and will only contain the CSRF prevention token parameter, if
# applicable. All query-string or form parameters sent with the original request will be
# discarded. If this property is not defined, CSRFGuard will instead auto-post the user to the
# original context and servlet path. The following configuration snippet instructs OWASP CSRFGuard to
# redirect the user to %servletContext%/index.html when the user visits a protected resource
# without having a corresponding CSRF token present in the HttpSession object:
#
# org.owasp.csrfguard.NewTokenLandingPage=%servletContext%/index.html
# Protected Methods
#
# The protected methods property (org.owasp.csrfguard.ProtectedMethods) defines a comma
# separated list of HTTP request methods that should be protected by CSRFGuard. The default
# list is an empty list which will cause all HTTP methods to be protected, thus preserving
# legacy behavior. This setting allows the user to inform CSRFGuard that only requests of the
# given types should be considered for protection. All HTTP methods not in the list will be
# considered safe (i.e. view only / unable to modify data). This should be used only when the
# user has concrete knowledge that all requests made via methods not in the list
# are safe (i.e. do not apply an action to any data) since it can actually introduce new
# security vulnerabilities. For example: the user thinks that all actionable requests are
# only available by POST requests when in fact some are available via GET requests. If the
# user has excluded GET requests from the list then they have introduced a vulnerability.
# The following configuration snippet instructs OWASP CSRFGuard to protect only the POST,
# PUT, and DELETE HTTP methods.
#
# org.owasp.csrfguard.ProtectedMethods=POST,PUT,DELETE
# or you can configure all to be protected, and specify which is unprotected. This is the preferred approach
# WSO2 : Since state-changing operations are not performed via HTTP GET,
# disabling CSRF validation for GET method.
org.owasp.csrfguard.UnprotectedMethods=GET
# Unique Per-Page Tokens
#
# The unique token per-page property (org.owasp.csrfguard.TokenPerPage) is a boolean value that
# determines if CSRFGuard should make use of unique per-page (i.e. URI) prevention tokens as
# opposed to unique per-session prevention tokens. When a user requests a protected resource,
# CSRFGuard will determine if a page specific token has been previously generated. If a page
# specific token has not yet been previously generated, CSRFGuard will verify the request was
# submitted with the per-session token intact. After verifying the presence of the per-session token,
# CSRFGuard will create a page specific token that is required for all subsequent requests to the
# associated resource. The per-session CSRF token can only be used when requesting a resource for
# the first time. All subsequent requests must have the per-page token intact or the request will
# be treated as a CSRF attack. This behavior can be changed with the org.owasp.csrfguard.TokenPerPagePrecreate
# property. Enabling this property will make CSRFGuard calculate the per page token prior to a first
# visit. This option only works with JSTL token injection and is useful for preserving the validity of
# links if the user pushes the back button. There may be a performance impact when enabling this option
# if the .jsp has a large number of proctected links that need tokens to be calculated.
# Use of the unique token per page property is currently experimental
# but provides a significant amount of improved security. Consider the exposure of a CSRF token using
# the legacy unique per-session model. Exposure of this token facilitates the attacker's ability to
# carry out a CSRF attack against the victim's active session for any resource exposed by the web
# application. Now consider the exposure of a CSRF token using the experimental unique token per-page
# model. Exposure of this token would only allow the attacker to carry out a CSRF attack against the
# victim's active session for a small subset of resources exposed by the web application. Use of the
# unique token per-page property is a strong defense in depth strategy significantly reducing the
# impact of exposed CSRF prevention tokens. The following configuration snippet instructs OWASP
# CSRFGuard to utilize the unique token per-page model:
#
# org.owasp.csrfguard.TokenPerPage=true
# org.owasp.csrfguard.TokenPerPagePrecreate=false
# WSO2 : Considering overhead, necessity, as well as current unintended behaviour
# of library after blocking a CSRF attack, disabling per-page tokens.
org.owasp.csrfguard.TokenPerPage=false
org.owasp.csrfguard.TokenPerPagePrecreate=false
# Token Rotation
#
# The rotate token property (org.owasp.csrfguard.Rotate) is a boolean value that determines if
# CSRFGuard should generate and utilize a new token after verifying the previous token. Rotation
# helps minimize the window of opportunity an attacker has to leverage the victim's stolen token
# in a targeted CSRF attack. However, this functionality generally causes navigation problems in
# most applications. Specifically, the 'Back' button in the browser will often cease to function
# properly. When a user hits the 'Back' button and interacts with the HTML, the browser may submit
# an old token causing CSRFGuard to incorrectly believe this request is a CSRF attack in progress
# (i.e. a 'false positive'). Users can prevent this scenario by preventing the caching of HTML pages
# containing FORM submissions using the cache-control header. However, this may also introduce
# performance problems as the browser will have to request HTML on a more frequent basis. The following
# configuration snippet enables token rotation:
#
# org.owasp.csrfguard.Rotate=true
# Ajax and XMLHttpRequest Support
#
# The Ajax property (org.owasp.csrfguard.Ajax) is a boolean value that indicates whether or not OWASP
# CSRFGuard should support the injection and verification of unique per-session prevention tokens for
# XMLHttpRequests. To leverage Ajax support, the user must not only set this property to true but must
# also reference the JavaScript DOM Manipulation code using a script element. This dynamic script will
# override the send method of the XMLHttpRequest object to ensure the submission of an X-Requested-With
# header name value pair coupled with the submission of a custom header name value pair for each request.
# The name of the custom header is the value of the token name property and the value of the header is
# always the unique per-session token value. This custom header is analogous to the HTTP parameter name
# value pairs submitted via traditional GET and POST requests. If the X-Requested-With header was sent
# in the HTTP request, then CSRFGuard will look for the presence and ensure the validity of the unique
# per-session token in the custom header name value pair. Note that verification of these headers takes
# precedence over verification of the CSRF token supplied as an HTTP parameter. More specifically,
# CSRFGuard does not verify the presence of the CSRF token if the Ajax support property is enabled and
# the corresponding X-Requested-With and custom headers are embedded within the request. The following
# configuration snippet instructs OWASP CSRFGuard to support Ajax requests by verifying the presence and
# correctness of the X-Requested-With and custom headers:
#
# org.owasp.csrfguard.Ajax=true
org.owasp.csrfguard.Ajax=true
# The default behavior of CSRFGuard is to protect all pages. Pages marked as unprotected will not be protected.
# If the Protect property is enabled, this behavior is reversed. Pages must be marked as protected to be protected.
# All other pages will not be protected. This is useful when the CsrfGuardFilter is aggressively mapped (ex: /*),
# but you only want to protect a few pages.
#
# org.owasp.csrfguard.Protect=true
# Unprotected Pages:
#
# The unprotected pages property (org.owasp.csrfguard.unprotected.*) defines a series of pages that
# should not be protected by CSRFGuard. Such configurations are useful when the CsrfGuardFilter is
# aggressively mapped (ex: /*). The syntax of the property name is org.owasp.csrfguard.unprotected.[PageName],
# where PageName is some arbitrary identifier that can be used to reference a resource. The syntax of
# defining the uri of unprotected pages is the same as the syntax used by the JavaEE container for uri mapping.
# Specifically, CSRFGuard will identify the first match (if any) between the requested uri and an unprotected
# page in order of declaration. Match criteria is as follows:
#
# Case 1: exact match between request uri and unprotected page
# Case 2: longest path prefix match, beginning / and ending /*
# Case 3: extension match, beginning *.
# Case 4: if the value starts with ^ and ends with $, it will be evaulated as a regex. Note that before the
# regex is compiled, any common variables will be substituted (e.g. %servletContext%)
# Default: requested resource must be validated by CSRFGuard
#
# The following code snippet illustrates the four use cases over four examples. The first two examples
# (Tag and JavaScriptServlet) look for direct URI matches. The third example (Html) looks for all resources
# ending in a .html extension. The next example (Public) looks for all resources prefixed with the URI path /MySite/Public/*.
# The last example looks for resources that end in Public.do
#
# org.owasp.csrfguard.unprotected.Tag=%servletContext%/tag.jsp
# org.owasp.csrfguard.unprotected.JavaScriptServlet=%servletContext%/JavaScriptServlet
# org.owasp.csrfguard.unprotected.Html=*.html
# org.owasp.csrfguard.unprotected.Public=%servletContext%/Public/*
# regex example starts with ^ and ends with $, and the %servletContext% is evaluated before the regex
# org.owasp.csrfguard.unprotected.PublicServlet=^%servletContext%/.*Public\.do$
#org.owasp.csrfguard.unprotected.Default=%servletContext%/
#org.owasp.csrfguard.unprotected.Upload=%servletContext%/upload.html
#org.owasp.csrfguard.unprotected.JavaScriptServlet=%servletContext%/JavaScriptServlet
#org.owasp.csrfguard.unprotected.Ajax=%servletContext%/ajax.html
#org.owasp.csrfguard.unprotected.Error=%servletContext%/error.html
#org.owasp.csrfguard.unprotected.Index=%servletContext%/index.html
#org.owasp.csrfguard.unprotected.JavaScript=%servletContext%/javascript.html
#org.owasp.csrfguard.unprotected.Tag=%servletContext%/tag.jsp
#org.owasp.csrfguard.unprotected.Redirect=%servletContext%/redirect.jsp
#org.owasp.csrfguard.unprotected.Forward=%servletContext%/forward.jsp
#org.owasp.csrfguard.unprotected.Session=%servletContext%/session.jsp
# Actions: Responding to Attacks
#
# The actions directive (org.owasp.csrfguard.action.*) gives the user the ability to specify one or more
# actions that should be invoked when a CSRF attack is detected. Every action must implement the
# org.owasp.csrfguard.action.IAction interface either directly or indirectly through the
# org.owasp.csrfguard.action.AbstractAction helper class. Many actions accept parameters that can be specified
# along with the action class declaration. These parameters are consumed at runtime and impact the behavior of
# the associated action.
#
# The syntax for defining and configuring CSRFGuard actions is relatively straight forward. Let us assume we wish
# to redirect the user to a default page when a CSRF attack is detected. A redirect action already exists within
# the CSRFGuard bundle and is available via the class name org.owasp.csrfguard.actions.Redirect. In order to enable
# this action, we capture the following declaration in the Owasp.CsrfGuard.properties file:
#
# syntax: org.owasp.csrfguard.action.[actionName]=[className]
# example: org.owasp.csrfguard.action.class.Redirect=org.owasp.csrfguard.actions.Redirect
#
# The aforementioned directive declares an action called "Redirect" (i.e. [actionName]) referencing the Java class
# "org.owasp.csrfguard.actions.Redirect" (i.e. [className]). Anytime a CSRF attack is detected, the Redirect action
# will be executed. You may be asking yourself, "but how do I specify where the user is redirected?"; this is where
# action parameters come into play. In order to specify the redirect location, we capture the following declaration
# in the Owasp.CsrfGuard.properties file:
#
# syntax: org.owasp.csrfguard.action.[actionName].[parameterName]=[parameterValue]
# example: org.owasp.csrfguard.action.Redirect.ErrorPage=%servletContext%/error.html
#
# The aforementioned directive declares an action parameter called "ErrorPage" (i.e. [parameterName]) with the value
# of "%servletContext%/error.html" (i.e. [parameterValue]) for the action "Redirect" (i.e. [actionName]). The
# Redirect action expects the "ErrorPage" parameter to be defined and will redirect the user to this location when
# an attack is detected.
#
#org.owasp.csrfguard.action.Empty=org.owasp.csrfguard.action.Empty
org.owasp.csrfguard.action.Log=org.owasp.csrfguard.action.Log
org.owasp.csrfguard.action.Log.Message=potential cross-site request forgery (CSRF) attack thwarted (user:%user%, ip:%remote_ip%, method:%request_method%, uri:%request_uri%, error:%exception_message%)
#org.owasp.csrfguard.action.Invalidate=org.owasp.csrfguard.action.Invalidate
# WSO2 : Disable redirecting user to an error page after blocking a CSRF attack
#org.owasp.csrfguard.action.Redirect=org.owasp.csrfguard.action.Redirect
#org.owasp.csrfguard.action.Redirect.Page=%servletContext%/error.html
#org.owasp.csrfguard.action.RequestAttribute=org.owasp.csrfguard.action.RequestAttribute
#org.owasp.csrfguard.action.RequestAttribute.AttributeName=Owasp_CsrfGuard_Exception_Key
# WSO2 : Disabling token rotation after blocking a CSRF attack, since this behaviour
# will break back navigation after blocking an attack.
#org.owasp.csrfguard.action.Rotate=org.owasp.csrfguard.action.Rotate
#org.owasp.csrfguard.action.SessionAttribute=org.owasp.csrfguard.action.SessionAttribute
#org.owasp.csrfguard.action.SessionAttribute.AttributeName=Owasp_CsrfGuard_Exception_Key
# WSO2 : Enable sending a 403 error after blocking a CSRF attack. Product teams
# can add error page that handles 403 or ???org.owasp.csrfguard.action.Error??? to
# display custom error pages.
org.owasp.csrfguard.action.Error=org.owasp.csrfguard.action.Error
org.owasp.csrfguard.action.Error.Code=403
org.owasp.csrfguard.action.Error.Message=Security violation.
# Token Name
#
# The token name property (org.owasp.csrfguard.TokenName) defines the name of the HTTP parameter
# to contain the value of the OWASP CSRFGuard token for each request. The following configuration
# snippet sets the CSRFGuard token parameter name to the value OWASP_CSRFTOKEN:
#
# org.owasp.csrfguard.TokenName=OWASP_CSRFTOKEN
# WSO2 : Since, CSRFGuard will send relevant token name as HTTP header
# ???X-??? prefix was added to express that this is a non-standard header.
org.owasp.csrfguard.TokenName=X-CSRF-Token
# Session Key
#
# The session key property (org.owasp.csrfguard.SessionKey) defines the string literal used to save
# and lookup the CSRFGuard token from the session. This value is used by the filter and the tag
# libraries to retrieve and set the token value in the session. Developers can use this key to
# programmatically lookup the token within their own code. The following configuration snippet sets
# the session key to the value OWASP_CSRFTOKEN:
#
# org.owasp.csrfguard.SessionKey=OWASP_CSRFTOKEN
org.owasp.csrfguard.SessionKey=OWASP_CSRFTOKEN
# Token Length
#
# The token length property (org.owasp.csrfguard.TokenLength) defines the number of characters that
# should be found within the CSRFGuard token. Note that characters are delimited by dashes (-) in groups
# of four. For cosmetic reasons, users are encourage to ensure the token length is divisible by four.
# The following configuration snippet sets the token length property to 32 characters:
#
# org.owasp.csrfguard.TokenLength=32
org.owasp.csrfguard.TokenLength=32
# Pseudo-random Number Generator
#
# The pseudo-random number generator property (org.owasp.csrfguard.PRNG) defines what PRNG should be used
# to generate the OWASP CSRFGuard token. Always ensure this value references a cryptographically strong
# pseudo-random number generator algorithm. The following configuration snippet sets the pseudo-random number
# generator to SHA1PRNG:
#
# org.owasp.csrfguard.PRNG=SHA1PRNG
org.owasp.csrfguard.PRNG=SHA1PRNG
# Pseudo-random Number Generator Provider
# The pseudo-random number generator provider property (org.owasp.csrfguard.PRNG.Provider) defines which
# provider's implementation of org.owasp.csrfguard.PRNG we should utilize. The following configuration
# snippet instructs the JVM to leverage SUN's implementation of the algorithm denoted by the
# org.owasp.csrfguard.PRNG property:
# org.owasp.csrfguard.PRNG.Provider=SUN
# WSO2 - Pseudo-random number generator provider should be configured based on
# environment (SUN/IBMJCE)
org.owasp.csrfguard.PRNG.Provider=SUN
# If not specifying the print config option in the web.xml, you can specify it here, to print the config
# on startup
# WSO2 : Disable printing configuration during start-up
org.owasp.csrfguard.Config.Print = false
###########################
## Javascript servlet settings if not set in web.xml
## https://www.owasp.org/index.php/CSRFGuard_3_Token_Injection
###########################
# leave this blank and blank in web.xml and it will read from META-INF/csrfguard.js from the jarfile
# Denotes the location of the JavaScript template file that should be consumed and dynamically
# augmented by the JavaScriptServlet class. The default value is WEB-INF/Owasp.CsrfGuard.js.
# Use of this property and the existence of the specified template file is required.
org.owasp.csrfguard.JavascriptServlet.sourceFile =
# Boolean value that determines whether or not the dynamic JavaScript code should be strict
# with regards to what links it should inject the CSRF prevention token. With a value of true,
# the JavaScript code will only place the token in links that point to the same exact domain
# from which the HTML originated. With a value of false, the JavaScript code will place the
# token in links that not only point to the same exact domain from which the HTML originated,
# but sub-domains as well.
org.owasp.csrfguard.JavascriptServlet.domainStrict = true
# Allows the developer to specify the value of the Cache-Control header in the HTTP response
# when serving the dynamic JavaScript file. The default value is private, maxage=28800.
# Caching of the dynamic JavaScript file is intended to minimize traffic and improve performance.
# Note that the Cache-Control header is always set to "no-store" when either the "Rotate"
# "TokenPerPage" options is set to true in Owasp.CsrfGuard.properties.
org.owasp.csrfguard.JavascriptServlet.cacheControl = private, maxage=28800
# Allows the developer to specify a regular expression describing the required value of the
# Referer header. Any attempts to access the servlet with a Referer header that does not
# match the captured expression is discarded. Inclusion of referer header checking is to
# help minimize the risk of JavaScript Hijacking attacks that attempt to steal tokens from
# the dynamically generated JavaScript. While the primary defenses against JavaScript
# Hijacking attacks are implemented within the dynamic JavaScript itself, referer header
# checking is implemented to achieve defense in depth.
org.owasp.csrfguard.JavascriptServlet.refererPattern = .*
# Similar to javascript servlet referer pattern, but this will make sure the referer of the
# javascript servlet matches the domain of the request. If there is no referer (proxy strips it?)
# then it will not fail. Generally this is a good idea to be true.
org.owasp.csrfguard.JavascriptServlet.refererMatchDomain = true
# Boolean value that determines whether or not the dynamic JavaScript code should
# inject the CSRF prevention token as a hidden field into HTML forms. The default
# value is true. Developers are strongly discouraged from disabling this property
# as most server-side state changing actions are triggered via a POST request.
org.owasp.csrfguard.JavascriptServlet.injectIntoForms = true
# if the token should be injected in GET forms (which will be on the URL)
# if the HTTP method GET is unprotected, then this should likely be false
# WSO2 : Disable JavaScript from injecting token value to HTTP GET based forms.
# This prevents token leakage that could occur when sending token in URL.
# State-changing actions should not be performed over HTTP GET
org.owasp.csrfguard.JavascriptServlet.injectGetForms = false
# if the token should be injected in the action in forms
# note, if injectIntoForms is true, then this might not need to be true
# WSO2 : Disable JavaScript from injecting token value to form action.
# This prevents token leakage that could occur when sending token in URL.
org.owasp.csrfguard.JavascriptServlet.injectFormAttributes = false
# Boolean value that determines whether or not the dynamic JavaScript code should
# inject the CSRF prevention token in the query string of src and href attributes.
# Injecting the CSRF prevention token in a URL resource increases its general risk
# of exposure to unauthorized parties. However, most JavaEE web applications respond
# in the exact same manner to HTTP requests and their associated parameters regardless
# of the HTTP method. The risk associated with not protecting GET requests in this
# situation is perceived greater than the risk of exposing the token in protected GET
# requests. As a result, the default value of this attribute is set to true. Developers
# that are confident their server-side state changing controllers will only respond to
# POST requests (i.e. discarding GET requests) are strongly encouraged to disable this property.
# WSO2 : Disable JavaScript from injecting token value to ???src??? and ???href???.
# This prevents token leakage that could occur when sending token in URL.
org.owasp.csrfguard.JavascriptServlet.injectIntoAttributes = false
# WSO2 : Changing X-Request-With header text to avoid unnecessary information disclosure.
org.owasp.csrfguard.JavascriptServlet.xRequestedWith = WSO2 CSRF Protection
###########################
## Config overlay settings if you have the provider above set to ConfigurationOverlayProvider
## This CSRF config provider uses Internet2 Configuration Overlays (documented on Internet2 wiki)
## By default the configuration is read from the Owasp.CsrfGuard.properties
## (which should not be edited), and the Owasp.CsrfGuard.overlay.properties overlays
## the base settings. See the Owasp.CsrfGuard.properties for the possible
## settings that can be applied to the Owasp.CsrfGuard.overlay.properties
###########################
# comma separated config files that override each other (files on the right override the left)
# each should start with file: or classpath:
# e.g. classpath:Owasp.CsrfGuard.properties, file:c:/temp/myFile.properties
org.owasp.csrfguard.configOverlay.hierarchy = classpath:Owasp.CsrfGuard.properties, classpath:Owasp.CsrfGuard.overlay.properties
# seconds between checking to see if the config files are updated
org.owasp.csrfguard.configOverlay.secondsBetweenUpdateChecks = 60
###########################
# please remove the below entry to enable protection for services.
org.owasp.csrfguard.unprotected.Services=%servletContext%/services/*
org.owasp.csrfguard.unprotected.Endpoints=%servletContext%/endpoints/*
org.owasp.csrfguard.unprotected.RestApi=%servletContext%/analytics/*
org.owasp.csrfguard.unprotected.JsApi=%servletContext%/portal/apis/analytics/*
org.owasp.csrfguard.unprotected.Servlet=%servletContext%/analytics-api/*
org.owasp.csrfguard.unprotected.ml=%servletContext%/api/login*
org.owasp.csrfguard.unprotected.passivests=%servletContext%/acs/*

@ -31,7 +31,7 @@
<!--The URL of the analytics data service is being hosted-->
<URL>http://localhost:9764</URL>
<URL>http://localhost:9765</URL>
<!-- A valid user name which have necessary permissions to use the remote services -->

@ -118,6 +118,27 @@
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<id>clean_target</id>
<phase>install</phase>
<configuration>
<tasks>
<delete dir="target/wso2iot-core-${product.iot.version}"/>
<delete dir="target/wso2iot-analytics-${product.iot.analytics.version}"/>
<delete dir="target/wso2iot-broker-${product.iot.broker.version}"/>
<delete file="target/${project.artifactId}-${project.version}.jar"/>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
@ -129,7 +150,6 @@
</build>
<properties>
<identity.jar.version>${carbon.identity.framework.version}</identity.jar.version>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

@ -0,0 +1,211 @@
<!--
~ Copyright (c) 2016, WSO2 Inc. (http://www.wso2.org) All Rights Reserved.
~
~ WSO2 Inc. licenses this file to you under the Apache License,
~ Version 2.0 (the "License"); you may not use this file except
~ in compliance with the License.
~ You may obtain a copy of the License at
~
~ http://www.apache.org/licenses/LICENSE-2.0
~
~ Unless required by applicable law or agreed to in writing,
~ software distributed under the License is distributed on an
~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
~ KIND, either express or implied. See the License for the
~ specific language governing permissions and limitations
~ under the License.
-->
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<parent>
<groupId>org.wso2</groupId>
<artifactId>wso2</artifactId>
<version>1</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>org.wso2.iot.devicemgt-plugins</groupId>
<artifactId>iot-devicetype-feature-installation</artifactId>
<version>${product.version}</version>
<packaging>pom</packaging>
<name>Creating custom distribution</name>
<url>http://wso2.org</url>
<build>
<plugins>
<plugin>
<groupId>org.wso2.maven</groupId>
<artifactId>carbon-p2-plugin</artifactId>
<version>1.5.3</version>
<executions>
<execution>
<id>2-p2-repo-generation</id>
<phase>package</phase>
<goals>
<goal>p2-repo-gen</goal>
</goals>
<configuration>
<metadataRepository>file:\${basedir}/samples/p2-repo</metadataRepository>
<artifactRepository>file:\${basedir}/samples/p2-repo</artifactRepository>
<publishArtifacts>true</publishArtifacts>
<publishArtifactRepository>true</publishArtifactRepository>
<featureArtifacts>
<featureArtifactDef>
org.wso2.carbon.devicemgt-plugins:org.wso2.carbon.device.mgt.iot.androidsense.feature:${carbon.device.mgt.plugin.version}
</featureArtifactDef>
<featureArtifactDef>
org.wso2.carbon.devicemgt-plugins:org.wso2.carbon.device.mgt.iot.arduino.feature:${carbon.device.mgt.plugin.version}
</featureArtifactDef>
<featureArtifactDef>
org.wso2.carbon.devicemgt-plugins:org.wso2.carbon.device.mgt.iot.raspberrypi.feature:${carbon.device.mgt.plugin.version}
</featureArtifactDef>
<featureArtifactDef>
org.wso2.carbon.devicemgt-plugins:org.wso2.carbon.device.mgt.iot.virtualfirealarm.feature:${carbon.device.mgt.plugin.version}
</featureArtifactDef>
</featureArtifacts>
</configuration>
</execution>
<execution>
<id>default-feature-install</id>
<phase>package</phase>
<goals>
<goal>p2-profile-gen</goal>
</goals>
<configuration>
<profile>default</profile>
<metadataRepository>file:\${basedir}/samples/p2-repo</metadataRepository>
<artifactRepository>file:\${basedir}/samples/p2-repo</artifactRepository>
<destination>../core/repository/components</destination>
<deleteOldProfileFiles>false</deleteOldProfileFiles>
<features>
<feature>
<id>org.wso2.carbon.device.mgt.iot.androidsense.feature.group</id>
<version>${carbon.device.mgt.plugin.version}</version>
</feature>
<feature>
<id>org.wso2.carbon.device.mgt.iot.arduino.feature.group</id>
<version>${carbon.device.mgt.plugin.version}</version>
</feature>
<feature>
<id>org.wso2.carbon.device.mgt.iot.raspberrypi.feature.group</id>
<version>${carbon.device.mgt.plugin.version}</version>
</feature>
<feature>
<id>org.wso2.carbon.device.mgt.iot.virtualfirealarm.feature.group</id>
<version>${carbon.device.mgt.plugin.version}</version>
</feature>
</features>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.1</version>
<executions>
<execution>
<id>default-feature-install</id>
<phase>package</phase>
<configuration>
<tasks>
<replace token="false" value="true"
dir="../core/repository/components/default/configuration/org.eclipse.equinox.simpleconfigurator">
<include name="**/bundles.info"/>
</replace>
<copy todir="../analytics/repository/deployment/server/carbonapps">
<fileset dir="../core/repository/deployment/server/carbonapps">
<include name="*.car"/>
</fileset>
</copy>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<pluginRepositories>
<pluginRepository>
<id>wso2.releases</id>
<name>WSO2 internal Repository</name>
<url>http://maven.wso2.org/nexus/content/repositories/releases/</url>
<releases>
<enabled>true</enabled>
<updatePolicy>daily</updatePolicy>
<checksumPolicy>ignore</checksumPolicy>
</releases>
</pluginRepository>
<pluginRepository>
<id>wso2.snapshots</id>
<name>Apache Snapshot Repository</name>
<url>http://maven.wso2.org/nexus/content/repositories/snapshots/</url>
<snapshots>
<enabled>true</enabled>
<updatePolicy>daily</updatePolicy>
</snapshots>
<releases>
<enabled>false</enabled>
</releases>
</pluginRepository>
<pluginRepository>
<id>wso2-nexus</id>
<name>WSO2 internal Repository</name>
<url>http://maven.wso2.org/nexus/content/groups/wso2-public/</url>
<releases>
<enabled>true</enabled>
<updatePolicy>daily</updatePolicy>
<checksumPolicy>ignore</checksumPolicy>
</releases>
</pluginRepository>
</pluginRepositories>
<repositories>
<!-- Before adding ANYTHING in here, please start a discussion on the dev list.
Ideally the Axis2 build should only use Maven central (which is available
by default) and nothing else. We had troubles with other repositories in
the past. Therefore configuring additional repositories here should be
considered very carefully. -->
<repository>
<id>wso2-nexus</id>
<name>WSO2 internal Repository</name>
<url>http://maven.wso2.org/nexus/content/groups/wso2-public/</url>
<releases>
<enabled>true</enabled>
<updatePolicy>daily</updatePolicy>
<checksumPolicy>ignore</checksumPolicy>
</releases>
</repository>
<repository>
<id>wso2.releases</id>
<name>WSO2 internal Repository</name>
<url>http://maven.wso2.org/nexus/content/repositories/releases/</url>
<releases>
<enabled>true</enabled>
<updatePolicy>daily</updatePolicy>
<checksumPolicy>ignore</checksumPolicy>
</releases>
</repository>
<repository>
<id>wso2.snapshots</id>
<name>WSO2 Snapshot Repository</name>
<url>http://maven.wso2.org/nexus/content/repositories/snapshots/</url>
<snapshots>
<enabled>true</enabled>
<updatePolicy>daily</updatePolicy>
</snapshots>
<releases>
<enabled>false</enabled>
</releases>
</repository>
</repositories>
<properties>
<carbon.device.mgt.plugin.version>2.2.6-SNAPSHOT</carbon.device.mgt.plugin.version>
</properties>
</project>
Loading…
Cancel
Save