You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

233 lines
8.9 KiB

{-# OPTIONS_HADDOCK hide #-}
{-# LANGUAGE PatternGuards #-}
{-# LANGUAGE OverloadedStrings #-}
module Network.Xmpp.Sasl.Common where
import Control.Applicative ((<$>))
import Control.Monad.Error
import qualified Data.Attoparsec.ByteString.Char8 as AP
import Data.Bits
import qualified Data.ByteString as BS
import qualified Data.ByteString.Base64 as B64
import Data.Maybe (maybeToList)
import qualified Data.Text as Text
import qualified Data.Text.Encoding as Text
import Data.Word (Word8)
import Data.XML.Pickle
import Data.XML.Types
import Network.Xmpp.Marshal
import Network.Xmpp.Sasl.StringPrep
import Network.Xmpp.Sasl.Types
import Network.Xmpp.Stream
import Network.Xmpp.Types
import qualified System.Random as Random
import Control.Monad.State.Strict
--makeNonce :: ErrorT AuthFailure (StateT StreamState IO) BS.ByteString
makeNonce :: IO BS.ByteString
makeNonce = do
g <- liftIO Random.newStdGen
return $ B64.encode . BS.pack . map toWord8 . take 15 $ Random.randoms g
where
toWord8 :: Int -> Word8
toWord8 x = fromIntegral x :: Word8
-- The <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/> element, with an
-- optional round-trip value.
saslInitE :: Text.Text -> Maybe Text.Text -> Element
saslInitE mechanism rt =
Element "{urn:ietf:params:xml:ns:xmpp-sasl}auth"
[("mechanism", [ContentText mechanism])]
(maybeToList $ NodeContent . ContentText <$> rt)
-- SASL response with text payload.
saslResponseE :: Maybe Text.Text -> Element
saslResponseE resp =
Element "{urn:ietf:params:xml:ns:xmpp-sasl}response"
[]
(maybeToList $ NodeContent . ContentText <$> resp)
-- The <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/> element.
xpSuccess :: PU [Node] (Maybe Text.Text)
xpSuccess = xpElemNodes "{urn:ietf:params:xml:ns:xmpp-sasl}success"
(xpOption $ xpContent xpId)
-- Parses the incoming SASL data to a mapped list of pairs.
pairs :: BS.ByteString -> Either String Pairs
pairs = AP.parseOnly . flip AP.sepBy1 (void $ AP.char ',') $ do
AP.skipSpace
name <- AP.takeWhile1 (/= '=')
_ <- AP.char '='
qt <- ((AP.char '"' >> return True) `mplus` return False)
content <- AP.takeWhile1 (AP.notInClass [',', '"'])
when qt . void $ AP.char '"'
return (name, content)
-- Failure element pickler.
xpFailure :: PU [Node] SaslFailure
xpFailure = xpWrap
(\(txt, (failure, _, _)) -> SaslFailure failure txt)
(\(SaslFailure failure txt) -> (txt,(failure,(),())))
(xpElemNodes
"{urn:ietf:params:xml:ns:xmpp-sasl}failure"
(xp2Tuple
(xpOption $ xpElem
"{urn:ietf:params:xml:ns:xmpp-sasl}text"
xpLangTag
(xpContent xpId))
(xpElemByNamespace
"urn:ietf:params:xml:ns:xmpp-sasl"
xpSaslError
(xpUnit)
(xpUnit))))
xpSaslError :: PU Text.Text SaslError
xpSaslError = ("xpSaslError", "") <?>
xpIso saslErrorFromText saslErrorToText
where
saslErrorToText SaslAborted = "aborted"
saslErrorToText SaslAccountDisabled = "account-disabled"
saslErrorToText SaslCredentialsExpired = "credentials-expired"
saslErrorToText SaslEncryptionRequired = "encryption-required"
saslErrorToText SaslIncorrectEncoding = "incorrect-encoding"
saslErrorToText SaslInvalidAuthzid = "invalid-authzid"
saslErrorToText SaslInvalidMechanism = "invalid-mechanism"
saslErrorToText SaslMalformedRequest = "malformed-request"
saslErrorToText SaslMechanismTooWeak = "mechanism-too-weak"
saslErrorToText SaslNotAuthorized = "not-authorized"
saslErrorToText SaslTemporaryAuthFailure = "temporary-auth-failure"
saslErrorFromText "aborted" = SaslAborted
saslErrorFromText "account-disabled" = SaslAccountDisabled
saslErrorFromText "credentials-expired" = SaslCredentialsExpired
saslErrorFromText "encryption-required" = SaslEncryptionRequired
saslErrorFromText "incorrect-encoding" = SaslIncorrectEncoding
saslErrorFromText "invalid-authzid" = SaslInvalidAuthzid
saslErrorFromText "invalid-mechanism" = SaslInvalidMechanism
saslErrorFromText "malformed-request" = SaslMalformedRequest
saslErrorFromText "mechanism-too-weak" = SaslMechanismTooWeak
saslErrorFromText "not-authorized" = SaslNotAuthorized
saslErrorFromText "temporary-auth-failure" = SaslTemporaryAuthFailure
saslErrorFromText _ = SaslNotAuthorized
-- Challenge element pickler.
xpChallenge :: PU [Node] (Maybe Text.Text)
xpChallenge = xpElemNodes "{urn:ietf:params:xml:ns:xmpp-sasl}challenge"
(xpOption $ xpContent xpId)
-- | Pickler for SaslElement.
xpSaslElement :: PU [Node] SaslElement
xpSaslElement = xpAlt saslSel
[ xpWrap SaslSuccess (\(SaslSuccess x) -> x) xpSuccess
, xpWrap SaslChallenge (\(SaslChallenge c) -> c) xpChallenge
]
where
saslSel (SaslSuccess _) = 0
saslSel (SaslChallenge _) = 1
-- | Add quotationmarks around a byte string.
quote :: BS.ByteString -> BS.ByteString
quote x = BS.concat ["\"",x,"\""]
saslInit :: Text.Text -> Maybe BS.ByteString -> ErrorT AuthFailure (StateT StreamState IO) ()
Tweak failure approach I'm assuming and defining the following: 1. XMPP failures (which can occur at the TCP, TLS, and XML/XMPP layers (as a stream error or forbidden input)) are fatal; they will distrupt the XMPP session. 2. All fatal failures should be thrown (or similar) by `session', or any other function that might produce them. 3. Authentication failures that are not "XMPP failures" are not fatal. They do not necessarily terminate the stream. For example, the developer should be able to make another authentication attempt. The `Session' object returned by `session' might be useful even if the authentication fails. 4. We can (and should) use one single data type for fatal failures. (Previously, both StreamFailure and TlsFailure was used.) 5. We can catch and rethrow/wrap IO exceptions in the context of the Pontarius XMPP error system that we decide to use, making the error system more intuitive, Haskell-like, and more straight-forward to implement. Calling `error' may only be done in the case of a program error (a bug). 6. A logging system will remove the need for many of the error types. Only exceptions that seem likely to affect the flow of client applications should be defined. 7. The authentication functions are prone to fatal XMPP failures in addition to non-fatal authentication conditions. (Previously, `AuthStreamFailure' was used to wrap these errors.) I'm hereby suggesting (and implementing) the following: `StreamFailure' and `TlsFailure' should be joined into `XmppFailure'. `pullStanza' and the other Connection functions used to throw `IOException', `StreamFailure' and `TlsFailure' exceptions. With this patch, they have been converted to `StateT Connection IO (Either XmppFailure a)' computations. They also catch (some) IOException errors and wrap them in the new `XmppIOException' constructor. `newSession' is now `IO (Either XmppFailure Session)' as well (being capable of throwing IO exceptions). Whether or not to continue to a) wrap `XmppFailure' failures in an `AuthStreamFailure' equivalent, or, b) treat the authentication functions just like the other functions that may result in failure (Either XmppFailure a), depends on how Network.Xmpp.Connection.auth will be used. Since the latter will make `auth' more consistent, as well as remove the need for a wrapped (and special-case) "AuthFailure" type, I have decided to give the "b" approach a try. (The drawback being, of course, that authentication errors can not be accessed through the use of ErrorT. Whether or not this might be a problem, I don't really know at this point.) As the SASL code (and SaslM) depended on `AuthStreamFailure', it remains for internal use, at least for the time-being. `session' is now an ErrorT computation as well. Some functions have been updated as hacks, but this will be changed if we decide to move forward with this approach.
13 years ago
saslInit mechanism payload = do
r <- lift . pushElement . saslInitE mechanism $
Text.decodeUtf8 . B64.encode <$> payload
case r of
Right () -> return ()
Left e -> throwError $ AuthStreamFailure e
-- | Pull the next element.
pullSaslElement :: ErrorT AuthFailure (StateT StreamState IO) SaslElement
pullSaslElement = do
mbse <- lift $ pullUnpickle (xpEither xpFailure xpSaslElement)
case mbse of
Tweak failure approach I'm assuming and defining the following: 1. XMPP failures (which can occur at the TCP, TLS, and XML/XMPP layers (as a stream error or forbidden input)) are fatal; they will distrupt the XMPP session. 2. All fatal failures should be thrown (or similar) by `session', or any other function that might produce them. 3. Authentication failures that are not "XMPP failures" are not fatal. They do not necessarily terminate the stream. For example, the developer should be able to make another authentication attempt. The `Session' object returned by `session' might be useful even if the authentication fails. 4. We can (and should) use one single data type for fatal failures. (Previously, both StreamFailure and TlsFailure was used.) 5. We can catch and rethrow/wrap IO exceptions in the context of the Pontarius XMPP error system that we decide to use, making the error system more intuitive, Haskell-like, and more straight-forward to implement. Calling `error' may only be done in the case of a program error (a bug). 6. A logging system will remove the need for many of the error types. Only exceptions that seem likely to affect the flow of client applications should be defined. 7. The authentication functions are prone to fatal XMPP failures in addition to non-fatal authentication conditions. (Previously, `AuthStreamFailure' was used to wrap these errors.) I'm hereby suggesting (and implementing) the following: `StreamFailure' and `TlsFailure' should be joined into `XmppFailure'. `pullStanza' and the other Connection functions used to throw `IOException', `StreamFailure' and `TlsFailure' exceptions. With this patch, they have been converted to `StateT Connection IO (Either XmppFailure a)' computations. They also catch (some) IOException errors and wrap them in the new `XmppIOException' constructor. `newSession' is now `IO (Either XmppFailure Session)' as well (being capable of throwing IO exceptions). Whether or not to continue to a) wrap `XmppFailure' failures in an `AuthStreamFailure' equivalent, or, b) treat the authentication functions just like the other functions that may result in failure (Either XmppFailure a), depends on how Network.Xmpp.Connection.auth will be used. Since the latter will make `auth' more consistent, as well as remove the need for a wrapped (and special-case) "AuthFailure" type, I have decided to give the "b" approach a try. (The drawback being, of course, that authentication errors can not be accessed through the use of ErrorT. Whether or not this might be a problem, I don't really know at this point.) As the SASL code (and SaslM) depended on `AuthStreamFailure', it remains for internal use, at least for the time-being. `session' is now an ErrorT computation as well. Some functions have been updated as hacks, but this will be changed if we decide to move forward with this approach.
13 years ago
Left e -> throwError $ AuthStreamFailure e
Right (Left e) -> throwError $ AuthSaslFailure e
Right (Right r) -> return r
-- | Pull the next element, checking that it is a challenge.
pullChallenge :: ErrorT AuthFailure (StateT StreamState IO) (Maybe BS.ByteString)
pullChallenge = do
e <- pullSaslElement
case e of
SaslChallenge Nothing -> return Nothing
SaslChallenge (Just scb64)
| Right sc <- B64.decode . Text.encodeUtf8 $ scb64
-> return $ Just sc
Clean up and additionally document AuthFailure (and XmppFailure) types As mentioned in a previous patch, the `AuthFailure' type signals a (non-fatal) SASL error condition. This is now reflected in the documentation. I went through the different constructors for the type, looking at how they were produced (thrown) and whether or not that information were useful for the application using Pontarius XMPP. To begin, I conclude that `AuthStreamFailure' is only used internally. It will probably be removed when the internal type signatures of the Sasl package are changed to conform with the rest of the `Error' computations of Pontarius XMPP. `AuthFailure' is not thrown as far as I can see, but is only used for the Error instance. `AuthNoAcceptableMechanism' is thrown by `xmppSasl' when none of the mechanisms offered by the server is specified as acceptable by the client. It wraps the mechanisms offered. I consider this information useful for client developers, and will therefor keep this constructor. `AuthSaslFailure' wraps a `SaslFailure' (from Types.hs) and is only thrown when `pullSaslElement' unpickles a SASL failure. This, together with `AuthNoAcceptableMechanism' above, could be considered the `normal' ways of which SASL might be failing. `AuthStringPrepFailure' is thrown if `prepCredentials' fails to stringprep-verify the credentials. This might be interesting for the client developer. As I think that `AuthIllegalCredentials' is more understandable, I have changed the name to that. `AuthNoStream' is thrown by `xmppSasl' when the stream state is `Closed'. This is the result of a client program error/bug. This patch removes this constructor and modifies the behaviour of xmppSasl to throw an `XmppFailure' instead. `AuthChallengeFailure' is thrown if `fromPairs' fails (in Scram.hs), if a challenge element could not be pulled (in Common.hs), by `saslFromJust' if a `Nothing' value is encountered (in Common.hs), in `pullFinalMessage' (`decode') if the success payload could not be decoded (in Common.hs), or if `toPairs' (in Common.hs) can not extract the pairs. Furthermore, `AuthServerAuthFailure' is thrown if there is no `v' value in the final message of the SCRAM handler. Finally, `AuthXmlFailure' is thrown when `pullSuccess' find something other than a success element (and, I'm guessing, a `SaslFailure' element). This can only happen if there is a bug in Pontarius XMPP or the server. The way I see it, all these failures are abnormal and are of no interest from the client application itself. I suggest that these events are logged instead, and that we signal any of these conditions with a new `AuthOtherFailure' constructor. I suggest that we remove the `AuthFailure' constructor, and use the `AuthOtherFailure' for the `Error' instance. The `AuthFailure' type and all its constructors are now documented. I also made some minor documentation enhancements to the `XmppFailure' type.
13 years ago
_ -> throwError AuthOtherFailure -- TODO: Log
Clean up and additionally document AuthFailure (and XmppFailure) types As mentioned in a previous patch, the `AuthFailure' type signals a (non-fatal) SASL error condition. This is now reflected in the documentation. I went through the different constructors for the type, looking at how they were produced (thrown) and whether or not that information were useful for the application using Pontarius XMPP. To begin, I conclude that `AuthStreamFailure' is only used internally. It will probably be removed when the internal type signatures of the Sasl package are changed to conform with the rest of the `Error' computations of Pontarius XMPP. `AuthFailure' is not thrown as far as I can see, but is only used for the Error instance. `AuthNoAcceptableMechanism' is thrown by `xmppSasl' when none of the mechanisms offered by the server is specified as acceptable by the client. It wraps the mechanisms offered. I consider this information useful for client developers, and will therefor keep this constructor. `AuthSaslFailure' wraps a `SaslFailure' (from Types.hs) and is only thrown when `pullSaslElement' unpickles a SASL failure. This, together with `AuthNoAcceptableMechanism' above, could be considered the `normal' ways of which SASL might be failing. `AuthStringPrepFailure' is thrown if `prepCredentials' fails to stringprep-verify the credentials. This might be interesting for the client developer. As I think that `AuthIllegalCredentials' is more understandable, I have changed the name to that. `AuthNoStream' is thrown by `xmppSasl' when the stream state is `Closed'. This is the result of a client program error/bug. This patch removes this constructor and modifies the behaviour of xmppSasl to throw an `XmppFailure' instead. `AuthChallengeFailure' is thrown if `fromPairs' fails (in Scram.hs), if a challenge element could not be pulled (in Common.hs), by `saslFromJust' if a `Nothing' value is encountered (in Common.hs), in `pullFinalMessage' (`decode') if the success payload could not be decoded (in Common.hs), or if `toPairs' (in Common.hs) can not extract the pairs. Furthermore, `AuthServerAuthFailure' is thrown if there is no `v' value in the final message of the SCRAM handler. Finally, `AuthXmlFailure' is thrown when `pullSuccess' find something other than a success element (and, I'm guessing, a `SaslFailure' element). This can only happen if there is a bug in Pontarius XMPP or the server. The way I see it, all these failures are abnormal and are of no interest from the client application itself. I suggest that these events are logged instead, and that we signal any of these conditions with a new `AuthOtherFailure' constructor. I suggest that we remove the `AuthFailure' constructor, and use the `AuthOtherFailure' for the `Error' instance. The `AuthFailure' type and all its constructors are now documented. I also made some minor documentation enhancements to the `XmppFailure' type.
13 years ago
-- | Extract value from Just, failing with AuthOtherFailure on Nothing.
saslFromJust :: Maybe a -> ErrorT AuthFailure (StateT StreamState IO) a
Clean up and additionally document AuthFailure (and XmppFailure) types As mentioned in a previous patch, the `AuthFailure' type signals a (non-fatal) SASL error condition. This is now reflected in the documentation. I went through the different constructors for the type, looking at how they were produced (thrown) and whether or not that information were useful for the application using Pontarius XMPP. To begin, I conclude that `AuthStreamFailure' is only used internally. It will probably be removed when the internal type signatures of the Sasl package are changed to conform with the rest of the `Error' computations of Pontarius XMPP. `AuthFailure' is not thrown as far as I can see, but is only used for the Error instance. `AuthNoAcceptableMechanism' is thrown by `xmppSasl' when none of the mechanisms offered by the server is specified as acceptable by the client. It wraps the mechanisms offered. I consider this information useful for client developers, and will therefor keep this constructor. `AuthSaslFailure' wraps a `SaslFailure' (from Types.hs) and is only thrown when `pullSaslElement' unpickles a SASL failure. This, together with `AuthNoAcceptableMechanism' above, could be considered the `normal' ways of which SASL might be failing. `AuthStringPrepFailure' is thrown if `prepCredentials' fails to stringprep-verify the credentials. This might be interesting for the client developer. As I think that `AuthIllegalCredentials' is more understandable, I have changed the name to that. `AuthNoStream' is thrown by `xmppSasl' when the stream state is `Closed'. This is the result of a client program error/bug. This patch removes this constructor and modifies the behaviour of xmppSasl to throw an `XmppFailure' instead. `AuthChallengeFailure' is thrown if `fromPairs' fails (in Scram.hs), if a challenge element could not be pulled (in Common.hs), by `saslFromJust' if a `Nothing' value is encountered (in Common.hs), in `pullFinalMessage' (`decode') if the success payload could not be decoded (in Common.hs), or if `toPairs' (in Common.hs) can not extract the pairs. Furthermore, `AuthServerAuthFailure' is thrown if there is no `v' value in the final message of the SCRAM handler. Finally, `AuthXmlFailure' is thrown when `pullSuccess' find something other than a success element (and, I'm guessing, a `SaslFailure' element). This can only happen if there is a bug in Pontarius XMPP or the server. The way I see it, all these failures are abnormal and are of no interest from the client application itself. I suggest that these events are logged instead, and that we signal any of these conditions with a new `AuthOtherFailure' constructor. I suggest that we remove the `AuthFailure' constructor, and use the `AuthOtherFailure' for the `Error' instance. The `AuthFailure' type and all its constructors are now documented. I also made some minor documentation enhancements to the `XmppFailure' type.
13 years ago
saslFromJust Nothing = throwError $ AuthOtherFailure -- TODO: Log
saslFromJust (Just d) = return d
-- | Pull the next element and check that it is success.
pullSuccess :: ErrorT AuthFailure (StateT StreamState IO) (Maybe Text.Text)
pullSuccess = do
e <- pullSaslElement
case e of
SaslSuccess x -> return x
Clean up and additionally document AuthFailure (and XmppFailure) types As mentioned in a previous patch, the `AuthFailure' type signals a (non-fatal) SASL error condition. This is now reflected in the documentation. I went through the different constructors for the type, looking at how they were produced (thrown) and whether or not that information were useful for the application using Pontarius XMPP. To begin, I conclude that `AuthStreamFailure' is only used internally. It will probably be removed when the internal type signatures of the Sasl package are changed to conform with the rest of the `Error' computations of Pontarius XMPP. `AuthFailure' is not thrown as far as I can see, but is only used for the Error instance. `AuthNoAcceptableMechanism' is thrown by `xmppSasl' when none of the mechanisms offered by the server is specified as acceptable by the client. It wraps the mechanisms offered. I consider this information useful for client developers, and will therefor keep this constructor. `AuthSaslFailure' wraps a `SaslFailure' (from Types.hs) and is only thrown when `pullSaslElement' unpickles a SASL failure. This, together with `AuthNoAcceptableMechanism' above, could be considered the `normal' ways of which SASL might be failing. `AuthStringPrepFailure' is thrown if `prepCredentials' fails to stringprep-verify the credentials. This might be interesting for the client developer. As I think that `AuthIllegalCredentials' is more understandable, I have changed the name to that. `AuthNoStream' is thrown by `xmppSasl' when the stream state is `Closed'. This is the result of a client program error/bug. This patch removes this constructor and modifies the behaviour of xmppSasl to throw an `XmppFailure' instead. `AuthChallengeFailure' is thrown if `fromPairs' fails (in Scram.hs), if a challenge element could not be pulled (in Common.hs), by `saslFromJust' if a `Nothing' value is encountered (in Common.hs), in `pullFinalMessage' (`decode') if the success payload could not be decoded (in Common.hs), or if `toPairs' (in Common.hs) can not extract the pairs. Furthermore, `AuthServerAuthFailure' is thrown if there is no `v' value in the final message of the SCRAM handler. Finally, `AuthXmlFailure' is thrown when `pullSuccess' find something other than a success element (and, I'm guessing, a `SaslFailure' element). This can only happen if there is a bug in Pontarius XMPP or the server. The way I see it, all these failures are abnormal and are of no interest from the client application itself. I suggest that these events are logged instead, and that we signal any of these conditions with a new `AuthOtherFailure' constructor. I suggest that we remove the `AuthFailure' constructor, and use the `AuthOtherFailure' for the `Error' instance. The `AuthFailure' type and all its constructors are now documented. I also made some minor documentation enhancements to the `XmppFailure' type.
13 years ago
_ -> throwError $ AuthOtherFailure -- TODO: Log
-- | Pull the next element. When it's success, return it's payload.
-- If it's a challenge, send an empty response and pull success.
pullFinalMessage :: ErrorT AuthFailure (StateT StreamState IO) (Maybe BS.ByteString)
pullFinalMessage = do
challenge2 <- pullSaslElement
case challenge2 of
SaslSuccess x -> decode x
SaslChallenge x -> do
_b <- respond Nothing
_s <- pullSuccess
decode x
where
decode Nothing = return Nothing
decode (Just d) = case B64.decode $ Text.encodeUtf8 d of
Clean up and additionally document AuthFailure (and XmppFailure) types As mentioned in a previous patch, the `AuthFailure' type signals a (non-fatal) SASL error condition. This is now reflected in the documentation. I went through the different constructors for the type, looking at how they were produced (thrown) and whether or not that information were useful for the application using Pontarius XMPP. To begin, I conclude that `AuthStreamFailure' is only used internally. It will probably be removed when the internal type signatures of the Sasl package are changed to conform with the rest of the `Error' computations of Pontarius XMPP. `AuthFailure' is not thrown as far as I can see, but is only used for the Error instance. `AuthNoAcceptableMechanism' is thrown by `xmppSasl' when none of the mechanisms offered by the server is specified as acceptable by the client. It wraps the mechanisms offered. I consider this information useful for client developers, and will therefor keep this constructor. `AuthSaslFailure' wraps a `SaslFailure' (from Types.hs) and is only thrown when `pullSaslElement' unpickles a SASL failure. This, together with `AuthNoAcceptableMechanism' above, could be considered the `normal' ways of which SASL might be failing. `AuthStringPrepFailure' is thrown if `prepCredentials' fails to stringprep-verify the credentials. This might be interesting for the client developer. As I think that `AuthIllegalCredentials' is more understandable, I have changed the name to that. `AuthNoStream' is thrown by `xmppSasl' when the stream state is `Closed'. This is the result of a client program error/bug. This patch removes this constructor and modifies the behaviour of xmppSasl to throw an `XmppFailure' instead. `AuthChallengeFailure' is thrown if `fromPairs' fails (in Scram.hs), if a challenge element could not be pulled (in Common.hs), by `saslFromJust' if a `Nothing' value is encountered (in Common.hs), in `pullFinalMessage' (`decode') if the success payload could not be decoded (in Common.hs), or if `toPairs' (in Common.hs) can not extract the pairs. Furthermore, `AuthServerAuthFailure' is thrown if there is no `v' value in the final message of the SCRAM handler. Finally, `AuthXmlFailure' is thrown when `pullSuccess' find something other than a success element (and, I'm guessing, a `SaslFailure' element). This can only happen if there is a bug in Pontarius XMPP or the server. The way I see it, all these failures are abnormal and are of no interest from the client application itself. I suggest that these events are logged instead, and that we signal any of these conditions with a new `AuthOtherFailure' constructor. I suggest that we remove the `AuthFailure' constructor, and use the `AuthOtherFailure' for the `Error' instance. The `AuthFailure' type and all its constructors are now documented. I also made some minor documentation enhancements to the `XmppFailure' type.
13 years ago
Left _e -> throwError $ AuthOtherFailure -- TODO: Log
Right x -> return $ Just x
-- | Extract p=q pairs from a challenge.
toPairs :: BS.ByteString -> ErrorT AuthFailure (StateT StreamState IO) Pairs
toPairs ctext = case pairs ctext of
Clean up and additionally document AuthFailure (and XmppFailure) types As mentioned in a previous patch, the `AuthFailure' type signals a (non-fatal) SASL error condition. This is now reflected in the documentation. I went through the different constructors for the type, looking at how they were produced (thrown) and whether or not that information were useful for the application using Pontarius XMPP. To begin, I conclude that `AuthStreamFailure' is only used internally. It will probably be removed when the internal type signatures of the Sasl package are changed to conform with the rest of the `Error' computations of Pontarius XMPP. `AuthFailure' is not thrown as far as I can see, but is only used for the Error instance. `AuthNoAcceptableMechanism' is thrown by `xmppSasl' when none of the mechanisms offered by the server is specified as acceptable by the client. It wraps the mechanisms offered. I consider this information useful for client developers, and will therefor keep this constructor. `AuthSaslFailure' wraps a `SaslFailure' (from Types.hs) and is only thrown when `pullSaslElement' unpickles a SASL failure. This, together with `AuthNoAcceptableMechanism' above, could be considered the `normal' ways of which SASL might be failing. `AuthStringPrepFailure' is thrown if `prepCredentials' fails to stringprep-verify the credentials. This might be interesting for the client developer. As I think that `AuthIllegalCredentials' is more understandable, I have changed the name to that. `AuthNoStream' is thrown by `xmppSasl' when the stream state is `Closed'. This is the result of a client program error/bug. This patch removes this constructor and modifies the behaviour of xmppSasl to throw an `XmppFailure' instead. `AuthChallengeFailure' is thrown if `fromPairs' fails (in Scram.hs), if a challenge element could not be pulled (in Common.hs), by `saslFromJust' if a `Nothing' value is encountered (in Common.hs), in `pullFinalMessage' (`decode') if the success payload could not be decoded (in Common.hs), or if `toPairs' (in Common.hs) can not extract the pairs. Furthermore, `AuthServerAuthFailure' is thrown if there is no `v' value in the final message of the SCRAM handler. Finally, `AuthXmlFailure' is thrown when `pullSuccess' find something other than a success element (and, I'm guessing, a `SaslFailure' element). This can only happen if there is a bug in Pontarius XMPP or the server. The way I see it, all these failures are abnormal and are of no interest from the client application itself. I suggest that these events are logged instead, and that we signal any of these conditions with a new `AuthOtherFailure' constructor. I suggest that we remove the `AuthFailure' constructor, and use the `AuthOtherFailure' for the `Error' instance. The `AuthFailure' type and all its constructors are now documented. I also made some minor documentation enhancements to the `XmppFailure' type.
13 years ago
Left _e -> throwError AuthOtherFailure -- TODO: Log
Right r -> return r
-- | Send a SASL response element. The content will be base64-encoded.
respond :: Maybe BS.ByteString -> ErrorT AuthFailure (StateT StreamState IO) ()
Tweak failure approach I'm assuming and defining the following: 1. XMPP failures (which can occur at the TCP, TLS, and XML/XMPP layers (as a stream error or forbidden input)) are fatal; they will distrupt the XMPP session. 2. All fatal failures should be thrown (or similar) by `session', or any other function that might produce them. 3. Authentication failures that are not "XMPP failures" are not fatal. They do not necessarily terminate the stream. For example, the developer should be able to make another authentication attempt. The `Session' object returned by `session' might be useful even if the authentication fails. 4. We can (and should) use one single data type for fatal failures. (Previously, both StreamFailure and TlsFailure was used.) 5. We can catch and rethrow/wrap IO exceptions in the context of the Pontarius XMPP error system that we decide to use, making the error system more intuitive, Haskell-like, and more straight-forward to implement. Calling `error' may only be done in the case of a program error (a bug). 6. A logging system will remove the need for many of the error types. Only exceptions that seem likely to affect the flow of client applications should be defined. 7. The authentication functions are prone to fatal XMPP failures in addition to non-fatal authentication conditions. (Previously, `AuthStreamFailure' was used to wrap these errors.) I'm hereby suggesting (and implementing) the following: `StreamFailure' and `TlsFailure' should be joined into `XmppFailure'. `pullStanza' and the other Connection functions used to throw `IOException', `StreamFailure' and `TlsFailure' exceptions. With this patch, they have been converted to `StateT Connection IO (Either XmppFailure a)' computations. They also catch (some) IOException errors and wrap them in the new `XmppIOException' constructor. `newSession' is now `IO (Either XmppFailure Session)' as well (being capable of throwing IO exceptions). Whether or not to continue to a) wrap `XmppFailure' failures in an `AuthStreamFailure' equivalent, or, b) treat the authentication functions just like the other functions that may result in failure (Either XmppFailure a), depends on how Network.Xmpp.Connection.auth will be used. Since the latter will make `auth' more consistent, as well as remove the need for a wrapped (and special-case) "AuthFailure" type, I have decided to give the "b" approach a try. (The drawback being, of course, that authentication errors can not be accessed through the use of ErrorT. Whether or not this might be a problem, I don't really know at this point.) As the SASL code (and SaslM) depended on `AuthStreamFailure', it remains for internal use, at least for the time-being. `session' is now an ErrorT computation as well. Some functions have been updated as hacks, but this will be changed if we decide to move forward with this approach.
13 years ago
respond m = do
r <- lift . pushElement . saslResponseE . fmap (Text.decodeUtf8 . B64.encode) $ m
case r of
Left e -> throwError $ AuthStreamFailure e
Right () -> return ()
-- | Run the appropriate stringprep profiles on the credentials.
-- May fail with 'AuthStringPrepFailure'
prepCredentials :: Text.Text -> Maybe Text.Text -> Text.Text
-> ErrorT AuthFailure (StateT StreamState IO) (Text.Text, Maybe Text.Text, Text.Text)
prepCredentials authcid authzid password = case credentials of
Clean up and additionally document AuthFailure (and XmppFailure) types As mentioned in a previous patch, the `AuthFailure' type signals a (non-fatal) SASL error condition. This is now reflected in the documentation. I went through the different constructors for the type, looking at how they were produced (thrown) and whether or not that information were useful for the application using Pontarius XMPP. To begin, I conclude that `AuthStreamFailure' is only used internally. It will probably be removed when the internal type signatures of the Sasl package are changed to conform with the rest of the `Error' computations of Pontarius XMPP. `AuthFailure' is not thrown as far as I can see, but is only used for the Error instance. `AuthNoAcceptableMechanism' is thrown by `xmppSasl' when none of the mechanisms offered by the server is specified as acceptable by the client. It wraps the mechanisms offered. I consider this information useful for client developers, and will therefor keep this constructor. `AuthSaslFailure' wraps a `SaslFailure' (from Types.hs) and is only thrown when `pullSaslElement' unpickles a SASL failure. This, together with `AuthNoAcceptableMechanism' above, could be considered the `normal' ways of which SASL might be failing. `AuthStringPrepFailure' is thrown if `prepCredentials' fails to stringprep-verify the credentials. This might be interesting for the client developer. As I think that `AuthIllegalCredentials' is more understandable, I have changed the name to that. `AuthNoStream' is thrown by `xmppSasl' when the stream state is `Closed'. This is the result of a client program error/bug. This patch removes this constructor and modifies the behaviour of xmppSasl to throw an `XmppFailure' instead. `AuthChallengeFailure' is thrown if `fromPairs' fails (in Scram.hs), if a challenge element could not be pulled (in Common.hs), by `saslFromJust' if a `Nothing' value is encountered (in Common.hs), in `pullFinalMessage' (`decode') if the success payload could not be decoded (in Common.hs), or if `toPairs' (in Common.hs) can not extract the pairs. Furthermore, `AuthServerAuthFailure' is thrown if there is no `v' value in the final message of the SCRAM handler. Finally, `AuthXmlFailure' is thrown when `pullSuccess' find something other than a success element (and, I'm guessing, a `SaslFailure' element). This can only happen if there is a bug in Pontarius XMPP or the server. The way I see it, all these failures are abnormal and are of no interest from the client application itself. I suggest that these events are logged instead, and that we signal any of these conditions with a new `AuthOtherFailure' constructor. I suggest that we remove the `AuthFailure' constructor, and use the `AuthOtherFailure' for the `Error' instance. The `AuthFailure' type and all its constructors are now documented. I also made some minor documentation enhancements to the `XmppFailure' type.
13 years ago
Nothing -> throwError $ AuthIllegalCredentials
Just creds -> return creds
where
credentials = do
ac <- normalizeUsername authcid
az <- case authzid of
Nothing -> Just Nothing
Just az' -> Just <$> normalizeUsername az'
pw <- normalizePassword password
return (ac, az, pw)
-- | Bit-wise xor of byte strings
xorBS :: BS.ByteString -> BS.ByteString -> BS.ByteString
xorBS x y = BS.pack $ BS.zipWith xor x y
-- | Join byte strings with ","
merge :: [BS.ByteString] -> BS.ByteString
merge = BS.intercalate ","
-- | Infix concatenation of byte strings
(+++) :: BS.ByteString -> BS.ByteString -> BS.ByteString
(+++) = BS.append