Links
Tags
Creators
Details
1.0.2
Compatibility
Changes
๐ชช BedrockPassport 1.0.2
BedrockPassport 1.0.2 improves skin persistence and fixes stale Passport state after interrupted Bedrock login sessions.
๐จ Persistent SkinsRestorer skins
Saved skins for Passport identities are now restored reliably after reconnecting.
BedrockPassport keeps the existing Floodgate skin handling, but now also performs a post-join check for the selected Java identity.
When SkinsRestorer is installed:
- the skin stored for the selected Java UUID can be restored after login
- switching between different Passport identities keeps their own saved skins
- reconnecting no longer loses a saved skin because the earlier Floodgate skin event happened too early
- if no saved SkinsRestorer skin exists, the normal Bedrock/Floodgate skin path is left unchanged
- SkinsRestorer remains optional
Tested with SkinsRestorer 15.12.6.
๐ Fixed stale Passport sessions after disconnect
Disconnecting during an authentication plugin's pre-join/configuration stage could previously leave a pending Passport reservation active until its timeout expired.
This could cause an immediate reconnect to be rejected with:
This Bedrock/Xbox account already has a pending Passport session.
BedrockPassport now listens for the Geyser session disconnect directly and immediately clears unfinished Passport state.
This includes:
- pending Java identity reservations
- unfinished Passport selector sessions
- pending untrusted Floodgate identity handoffs
- temporary skin tracking state
The reservation timeout is still kept as a fallback for abnormal cases where no disconnect event is received.
๐ Authentication behavior
The security model introduced in 1.0.1 is unchanged.
A saved Passport identity is still treated as untrusted identity selection, not proof of account ownership.
Authentication plugins must still perform their normal password, registration, PIN, form, or other verification.
AuthMeReloaded 6.0.1-b2770 was tested successfully with the Passport login flow.
๐ ๏ธ Other changes
- Added a dedicated Geyser session lifecycle bridge
- Improved cleanup of unfinished identity handoffs
- Updated the project version to 1.0.2
- Updated documentation for the new skin and reconnect behavior
- Internal development files are now excluded from the public repository
Projects on Modrinth are automatically available through a Maven repository for use with JVM build tools such as Gradle. To learn more about the Modrinth Maven API, click here.
Note: When available, you should use the creator's maven repo instead as it will have transitive dependency information that the Modrinth Maven API does not. You may also end up with duplicate dependencies if you use a mix of Modrinth and non-Modrinth Maven repositories for your dependencies, because the group identifier will be different when served through the Modrinth Maven API.
Maven coordinates:
Version ID:
build.gradle:
repositories {
exclusiveContent {
forRepository {
maven {
name = "Modrinth"
url = "https://api.modrinth.com/maven"
}
}
// forRepositories(fg.repository) // Uncomment when using ForgeGradle
filter {
includeGroup "maven.modrinth"
}
}
}
// Standard Gradle dependency
dependencies {
implementation "maven.modrinth:xlbqOfvO:UIsQy7RK"
}
// Legacy Loom dependency
dependencies {
modImplementation "maven.modrinth:xlbqOfvO:UIsQy7RK"
}

