Status Update
No update yet.
Comments
jp...@google.com
Thanks for reporting this and providing some code snippets! Additionally, if you have a project I would be able to clone that reproduces the issue it would definitely help as well!
bl...@google.com
You can clone this:
Run the Main Activity, scroll to the end of the list: I join a screen of the issue.
jh...@sps-k12.com
Thanks for providing a sample project! Looks like this is an issue with how we conflate item accesses when triggering prefetch.
jp...@google.com
Branch: androidx-master-dev
commit 190a76ec743552627310e024976fd5896e989acb
Author: Dustin Lam <dustinlam@google.com>
Date: Mon Sep 28 13:54:08 2020
Prioritize hints from more recent presenter state
Currently we only use itemsPresentedAfter, which only accounts for the
placeholderOffset from the last page, but this value is insufficient to
determine which hint loads more items in cases where the last/first
pageOffset changes on presenter side.
As a result, we'll drop hints that would load more items in favor of
hints that came from a past presenter state that was scroll further into
placeholders.
This change fixes the above by always prioritizing new incoming hints if
the first/last pageOffset of presenter state changes.
RelNote: "N/A"
Fixes: 169259468
Test: ./gradlew paging:paging-common:test
Change-Id: Iffda3a0eb7abe162045893367b4781daf75adb01
M paging/common/api/current.txt
M paging/common/api/public_plus_experimental_current.txt
M paging/common/api/restricted_current.txt
M paging/common/src/main/kotlin/androidx/paging/PageFetcherSnapshot.kt
M paging/common/src/test/kotlin/androidx/paging/PageFetcherSnapshotTest.kt
ho...@gmail.com
I agree, I couldn't find a better place for this. It's also annoying that openid.net seems to be down with a 503 today, but you can still view the link above on the wayback machine at
The Authorization Server SHOULD prompt the End-User for reauthentication. If it cannot reauthenticate the End-User, it MUST return an error, typically login_required.
Reading MUST and SHOULD according to RFC2119 (
In any case, the former behavior is certainly preferable, as I described in the Impact section. Microsoft SSO, for example, does implement this functionality, and some of our customers have thought about a switch to Microsoft-based products purely over this concern.
fi...@gmail.com
to...@gmail.com
Edit 03/31/2025 - To add to my comment above, it makes sense to keep the experience very simple/easy for normal Google accounts. But, but Google Workspace accounts, this should be an option that an administrator can turn on. Take for example, a police department that uses Google Workspace for their officers. There needs to be a way to allow a particular OIDC client, for example, to be able to trigger the re-authentication when needed. Otherwise, Google Workspace is NOT compliant with CJIS security policy and cannot be used by Police Departments.
Description
Description
The OIDC specification (athttps://openid.net/specs/openid-connect-core-1_0.html ) states that when the
promptparameter is set tologin:However, the Google SSO workflow doesn't seem to conform to this part of the OpenID Connect specification, despite claiming to do so athttps://developers.google.com/identity/openid-connect/openid-connect .
In other words, when an SSO button's href includes
...&prompt=login, the user SHOULD be prompted to enter their password again before returning to the original site. However, while that parameter does not produce an error, it also seems to do nothing.Impact
This issue has led to trouble in the K12 sector, where students are likely to take even small windows of opportunity to "prank" each other by changing important settings in apps if a peer turns away from their device momentarily. Implementing this part of the OIDC specification would allow apps to re-validate users immediately before changing important settings or viewing private information, just as Google does in certain parts of its own Workspace application.