This repository has been archived by the owner on Nov 29, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 56
Version Changes
Jose C edited this page Jan 3, 2018
·
3 revisions
- Some methods for
AuthenticatorService
move fromOptionT
toF[A]
. - Changed type param order in TSecAuthService for partial unification #90 @jarreds
- Added error handler for authed service (doesn't break existing code, but it does break binary)
-
TSecAuthService
now composes with<+>
! - You can now add specific authorization to specific
TSecAuthedService
s, usingwithAuthorization
- HMAC signing can now take arbitrary length keys (Thank you to @fiadliel for bringing this to light) as per the spec. (bugfix)
- Fixed rolling window authentication.
Type signatures are now consistent over All modules. This means types have gone from:
- For message authentication codes:
A
toMAC[A]
(i.eHMACSHA256
toMAC[SHA256]
) - For digest hashes:
A
toCryptoHash[A]
(i.eSHA256
toCryptoHash[SHA256]
) - For password hashes:
A
toPasswordHash[A]
- For signatures:
A
toCryptoSignature[A]
However, the underlying type itself is the same, so code itself should not change, except for
passwordhashers
.
The following passwordhasher changes were implemented:
- The default methods are now
hashpw
,hashpwUnsafe
,checkpw
andcheckpwUnsafe
. Methods withunsafe
in the name are impure. - Password Hashing has received a slight speed optimization for BCrypt via our
ManagedRandom
, andStringBuilder
overStringBuffer
, especially considering no synchronization is needed. The dependency onorg.mindrot.JBCrypt
is gone, we have forked our own slightly more restrictive but safer version (our version uses byte arrays to hash, not passwords. The crypto primitive logic is the same). - #58 Byte arrays are now the default, and they are wiped after password hashing.
- BCrypt now includes a way to vary the number of rounds
hashpwWithRounds
. This doesn't change password checking whatsoever, it's a net gain.
JWT received a few changes as well:
- JWT methods now default to monadic. This makes sense, as
tsec
is an FP-first library. Thus now, allJWTMacM
methods have becomeJWTMac
by default, andJWTMac
has becomeJWTMacImpure
, same withJWTSig
.
Tsec is FP-first, thus JCA primitives should be pure by default, thus the following were renamed:
-
JCAMacPure
=>JCAMac
-
JCASignerPure
=>JCASigner
-
JCAAEADPure
=>JCAAEAD
-
JCASymmPure
=>JCASymmetricCipher
For the converse, the impure versions now all have Impure
in their name. They are:
JCAMacImpure
JCASignerImpure
JCAAEADImpure
JCASymmCipherImpure
- Passwordhashers now operate on byte and char arrays, and wipe the data from the original source arrays when done (with a bit of inlining optimization done by @hrhino)
- MAC, Signature and MessageDigest primitives now have convenience methods to not have to work directly
on the algebra instances, i.e
JCAMac.sign[IO, A]
. See the source on the primitive for more details. - Update http4s to 0.18.0-M6
- All newtypes expose their
cats.evidence.Is
, to be able to use thesubst
methods. i.e, if you need to work with a doobieMeta[String]
object, you can usePasswordHash.is[SCrypt].substitute
to get aMeta[PasswordHash[SCrypt]]
- Due to the type sigs being consistent, a few code smells have gone away: In particular,
StringEV
andByteEV
are no longer necessary, and thus have been removed. This has no impact on the user level api. - the
JWT
trait now takes two type parameters, thusJWSSignature
is no longer needed: the signature itself now depends on the primitive used:Mac
ORCryptoSignature
Updates http4s version to 0.18.0-M5
Updates http4s version to 0.18.0-M5
This release adds:
- Credentials-based authentication
- CSRF
- Improved Documentation
- Bearer Token Authenticator
- SecureRandomId generation
Breaking changes:
- JWTClaims
jwtId
changed from UUID to String, to be able to useSecureRandomId
- TaggedByteSyntax changed from
toArray
toasByteArray
-
Alg
type parameter removed from authenticator -
BackingStore
signature changed. -
Authorization
signature changed to include the token type - Type parameters are now consistent across all authorization and authentication related classes, with left
to right ordering with priority:
Effect type > Id type > User Type > Token type
. Auth token type is always last. -
SignedCookie
andAEADCookie
methodfromRaw
changed toapply