Resolving Security String Issues
This details how to resolve issues with Security String Delivery
See below for a variety of solutions to common problems
Security String is not received by user, check system logs to ensure that it is being sent from the server
Does the user exist in Swivel
Check that the user has dual channel permissions
Is a valid transport set for the user i.e. telephone number/email address, check system logs
Are they a member of a transport group
Are the correct transport attributes defined under Transport/Attribute see Transport_Attribute
Have they been configured to receive more than 1 security string per message, Example: if the user is set to receive 99 security strings per message, they will need to authenticate 99 times before a new message is sent.
Ensure that Dual Channel On Demand is set to No unless a mechanism has been set for requesting the security string on Demand
If a message is received without the security string, check the Security String Formatting under Transport and ensure that %NUMBER%CR%LF%STRING is present, specifically %STRING see Transport Configuration
If a user already has a transport, but transport setting is switched to one they have no value for, they retain their old transport, rather than being cleared.
If the transport is not correctly formatted
- check the transport text for errors
- For SMS gateways, check the service provider does not reformat or ignore certain parameters or apply filters
Has the SMS text message timed out for On demand authentication? see SMS Timeout
Ensure that a user is a member of only one Swivel group. Membership of multiple groups can mean that a group with no transports will be used, and therefore the security strings will not be sent out.
It may be possible that the transport queue has become locked and Tomcat may need restarting or the server rebooting.
Are security strings not sent on user creation? Is the "Re-send credentials on destination change" set to No on the Transport -> General screen? (This option has been removed in swivel 3.9.6 onwards) and the Swivel version less than 3.9.6? If so set this value to Yes and add an account, verify the security string is sent. If this resolves the issue use Yes for this or upgrade to 3.9.6 or later.
Swivel 126.96.36.1997 contains a bug that prevents sending of the initial security string. To resolve upgrade to 188.8.131.526 or later.
Swivel 3.10 after an upgrade to Swivel 3.10, perform a User Sync and test.
Check a users transport settings under User Administration by selecting View then Transport, as below:
No Transport Attribute found for User
The user does not have a transport defined (i.e. a phone number or email address), or the Transport Attribute has not been defined for the group.
TRANSPORT_LOADED: YPF_SMTP WEXCEPTION IN TRANSPORT:id YPF_SMTPnull
A bug in Swivel 3.8 prevents the delivery of security strings by SMTP (email), it does not affect SMTP to SMS or other transport classes, it also does not affect alerts. Upgrade to a more recent version.
Incorrect transport specified for user. Verify their group memberships and that the correct Transport Attribute is used.