Return-Path: 
 <dev-return-6471-apmail-shiro-dev-archive=shiro.apache.org@shiro.apache.org>
X-Original-To: apmail-shiro-dev-archive@www.apache.org
Delivered-To: apmail-shiro-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 705BA17417
	for <apmail-shiro-dev-archive@www.apache.org>;
 Sun, 13 Sep 2015 23:17:46 +0000 (UTC)
Received: (qmail 86317 invoked by uid 500); 13 Sep 2015 23:17:46 -0000
Delivered-To: apmail-shiro-dev-archive@shiro.apache.org
Received: (qmail 86117 invoked by uid 500); 13 Sep 2015 23:17:46 -0000
Mailing-List: contact dev-help@shiro.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@shiro.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@shiro.apache.org>
List-Post: <mailto:dev@shiro.apache.org>
List-Id: <dev.shiro.apache.org>
Reply-To: dev@shiro.apache.org
Delivered-To: mailing list dev@shiro.apache.org
Received: (qmail 85786 invoked by uid 99); 13 Sep 2015 23:17:46 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 13 Sep 2015 23:17:46 +0000
Date: Sun, 13 Sep 2015 23:17:46 +0000 (UTC)
From: "Carsten Englert (JIRA)" <jira@apache.org>
To: dev@shiro.apache.org
Message-ID: <JIRA.12844547.1436763732000.325623.1442186266120@Atlassian.JIRA>
In-Reply-To: <JIRA.12844547.1436763732000@Atlassian.JIRA>
References: <JIRA.12844547.1436763732000@Atlassian.JIRA>
 <JIRA.12844547.1436763732283@arcas>
Subject: [jira] [Commented] (SHIRO-536) Session token in url
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


    [ https://issues.apache.org/jira/browse/SHIRO-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14742719#comment-14742719 ] 

Carsten Englert commented on SHIRO-536:
---------------------------------------

Any news on this?

I'm struggling to find a workaround as well, since setting a specific SessionDAO seems to be mandatory in order to get [Shiro working in a cluster environment|http://shiro.apache.org/session-management.html#SessionManagement-SessionClustering].

Giving up the more secure Cookie tracking mode in favor of the Session ID being included in the URL is not an option.

> Session token in url
> --------------------
>
>                 Key: SHIRO-536
>                 URL: https://issues.apache.org/jira/browse/SHIRO-536
>             Project: Shiro
>          Issue Type: Bug
>          Components: Authentication (log-in), Session Management
>    Affects Versions: 1.2.3
>         Environment: Security
>            Reporter: Nagaraju Kurma
>              Labels: security
>
> Hello Team,
> As we know that this is one of the vulnerability challenges where we are supposed to remove JSESSIONID from the url.
> I observed that there is a possibility with the plain servlet api 3.x version with the web.xml configuration which disables the JSESSIONID from the url is
> <session-config>
>  <tracking-mode>COOKIE</tracking-mode>
> </session-config>
> But shiro will identify and reads the above configuration if and only if shiro xml contains session manager configuration with the class 
> <bean id="sessionManager" class="org.apache.shiro.web.session.mgt.ServletContainerSessionManager"></bean>
> But the limitations with above class are....
> 1) No session listeners configuration
> 2) No Session dao configuration
> 3) No Session validation scheduler configuration
> 4) No invalid session deletion configuration
> ...
> ...
> etc
> But removing session token from the url is possible with this.
> To achieve all the above limitations i am using the following session manager
> <bean id="sessionManager" class="org.apache.shiro.web.session.mgt.DefaultWebSessionManager"></bean>
> But with this i unable to hide session token from the url as it doesnt read web.xml configuration and context.xml...etc
> Does anybody having any work around this or is there any other session manger which will include both above 2 session managers functionality so that i can achieve all the above limitations and the session token issue. 
> I am facing the issues with these insufficient configuration, Could anybody please suggest the way forward..



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)