From user-return-7596-archive-asf-public=cust-asf.ponee.io@shiro.apache.org Wed Jan 10 09:27:03 2018 Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id 688B618062E for ; Wed, 10 Jan 2018 09:27:03 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 58EEE160C23; Wed, 10 Jan 2018 08:27:03 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 78F48160C2E for ; Wed, 10 Jan 2018 09:27:02 +0100 (CET) Received: (qmail 1720 invoked by uid 500); 10 Jan 2018 08:27:01 -0000 Mailing-List: contact user-help@shiro.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@shiro.apache.org Delivered-To: mailing list user@shiro.apache.org Received: (qmail 1709 invoked by uid 99); 10 Jan 2018 08:27:01 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Jan 2018 08:27:01 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 04E58C19AC for ; Wed, 10 Jan 2018 08:27:01 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.169 X-Spam-Level: * X-Spam-Status: No, score=1.169 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=me.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id sIoleEQJRMIF for ; Wed, 10 Jan 2018 08:27:00 +0000 (UTC) Received: from pv33p04im-asmtp002.me.com (pv33p04im-asmtp002.me.com [17.143.181.11]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id BED6D5F2C4 for ; Wed, 10 Jan 2018 08:26:59 +0000 (UTC) Received: from process-dkim-sign-daemon.pv33p04im-asmtp002.me.com by pv33p04im-asmtp002.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P2B00000Z5J8D00@pv33p04im-asmtp002.me.com> for user@shiro.apache.org; Wed, 10 Jan 2018 08:26:53 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=04042017; t=1515572813; bh=K/FsjdZEXQYf0l75X/lcEYXbbIrylPlXPLzpT7iylyw=; h=From:MIME-version:Content-type:Subject:Date:To:Message-id; b=xR8OHZqzcI2ASkpzcpuAH4JyywjA227j3dtW/KToHB7fNH3qaEKjXj2Kw4at04be9 Xx/WUyX6CtyU4wFs2/rQTWcCXG4jKS3zGyAZLIXXDiBbqb1qyE6+wmw3fCY9UDQ1vH LgGdztwlDw6AItm3KS7rGiz4TsWhyu0ylEmCgxw1xJISUnPwO0/atqOQdIcxAAxN96 UhYen3Mlgt9weHvyMFG/i9pQjxJ6oHApfmOuzvnQCM+pwqE65hkx8H8C0ETrXP77W6 xglvIdi4E9KamTOD3GCjgQK7YHXmNyDaam7gpHEqU+4xy5G39W7BdkpWKC6A1NFZX9 ojjCIjfuhe9XQ== Received: from icloud.com ([127.0.0.1]) by pv33p04im-asmtp002.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P2B00AIQZGI6T30@pv33p04im-asmtp002.me.com> for user@shiro.apache.org; Wed, 10 Jan 2018 08:26:53 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-01-10_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=4 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1801100121 From: =?utf-8?Q?Bj=C3=B6rn_Raupach?= MIME-version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Content-type: multipart/alternative; boundary="Apple-Mail=_31C53DA4-C49D-483E-B9A5-4C66B3819E6B" X-Clacks-Overhead: GNU Terry Pratchett Subject: Re: RememberMeManager in Database Date: Wed, 10 Jan 2018 09:26:41 +0100 References: To: user@shiro.apache.org In-reply-to: Message-id: <828BCE83-AE12-4B11-8E1D-97D635E3C0C0@me.com> X-Mailer: Apple Mail (2.3445.5.20) --Apple-Mail=_31C53DA4-C49D-483E-B9A5-4C66B3819E6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Brian, > On 9. Jan 2018, at 20:20, Brian Demers wrote: >=20 > Sounds like that could work. As for invalidating a single remembered = me session, I don't think you would need to deal with an individual = cipher, simply deleting the user's key from your database would do it = (as the next request would fail to lookup the rememberMe key). >=20 AbstractRememberMeManager already assumes using a cipher. = CookieRememberMeManager inherits this. What do you think: make a new = class and inherit from CookieRememberMeManager and override the unneeded = stuff or create a new class, implement RememberMeManager and duplicate = code from CookieRememberMeManager? > You may also need to heavily depend on caching, as each request might = require a DB lookup (but that is up to you and your usage patterns) true, we already use permission, so every request already hits the = database. Compared to everything else that is going for loading a web = page this single statement is neglectable. I don=E2=80=99t expect = another query for rememberMe to cause much issue. But agreed, this = really depends on individual usage patterns. Might work for some, not = for everyone.=20 >=20 > Keep us posted! Since we need this feature I can dedicate company time on this matter. = Will work on this in my repo and open a pull request once I have = something figured out. Might need some help troubleshooting.=20 > -Brian >=20 >=20 > On Tue, Jan 9, 2018 at 10:02 AM, Bj=C3=B6rn Raupach > wrote: > Hi there, >=20 > has anyone worked on a RememberMeManager that stores the the = credentials in the database? >=20 > As far as I can tell the current CookieRememberMeManager encrypts the = principal and store the encrypted value in a cookie. Identity is = restored if we can decrypt the supplied cookie value from the user = agent. >=20 > Would it be possible to offload this to a database? Say the cookie = value is just a nonce. A uuid for example. The RememberMeManager = implementation must then look into the database for the nonce. If there = is a matching principal it returns a successful identity. Otherwise it = doesn=E2=80=99t. >=20 > This way we could invalidate remembered sessions for some users and = not for all by means of changing the cipher key. >=20 > Does this make sense? Could this work? >=20 > Any ideas would be appreciated. >=20 > kind regards > Bj=C3=B6rn >=20 --Apple-Mail=_31C53DA4-C49D-483E-B9A5-4C66B3819E6B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Brian,

On 9. Jan 2018, at 20:20, Brian Demers <brian.demers@gmail.com> wrote:

Sounds like that could work.  As for invalidating a = single remembered me session, I don't think you would need to deal with = an individual cipher, simply deleting the user's key from your database = would do it (as the next request would fail to lookup the rememberMe = key).


AbstractRememberMeManager already assumes using a = cipher. CookieRememberMeManager inherits this. What do you think: make a = new class and inherit from CookieRememberMeManager and override the = unneeded stuff or create a new class, implement RememberMeManager and = duplicate code from CookieRememberMeManager?

You may also need to heavily = depend on caching, as each request might require a DB lookup (but that = is up to you and your usage = patterns)

true, we already use permission, so every request = already hits the database. Compared to everything else that is going for = loading a web page this single statement is neglectable. I don=E2=80=99t = expect another query for rememberMe to cause much issue. But agreed, = this really depends on individual usage patterns. Might work for some, = not for everyone. 

Keep us = posted!

Since= we need this feature I can dedicate company time on this matter. Will = work on this in my repo and open a pull request once I have something = figured out. Might need some help troubleshooting. 

-Brian

On Tue, Jan 9, 2018 at 10:02 AM, = Bj=C3=B6rn Raupach <raupach@me.com> wrote:
Hi there,

has anyone worked on a RememberMeManager that stores the the credentials = in the database?

As far as I can tell the current CookieRememberMeManager encrypts the = principal and store the encrypted value in a cookie. Identity is = restored if we can decrypt the supplied cookie value from the user = agent.

Would it be possible to offload this to a database? Say the cookie value = is just a nonce. A uuid for example. The RememberMeManager = implementation must then look into the database for the nonce. If there = is a matching principal it returns a successful identity. Otherwise it = doesn=E2=80=99t.

This way we could invalidate remembered sessions for some users and not = for all by means of changing the cipher key.

Does this make sense? Could this work?

Any ideas would be appreciated.

kind regards
Bj=C3=B6rn


= --Apple-Mail=_31C53DA4-C49D-483E-B9A5-4C66B3819E6B--