Difference between revisions of "Resolving Security String Issues"

Latest revision as of 12:52, 11 May 2017

Overview

This details how to resolve issues with Security String Delivery

Prerequisites

Swivel server

Symptoms

See below for a variety of solutions to common problems

Solution

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 3.9.6.927 contains a bug that prevents sending of the initial security string. To resolve upgrade to 3.9.6.1046 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:

Error Messages

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.

LOG_ERROR_WRITING_TO_TRANSPORT_QUEUE

Incorrect transport specified for user. Verify their group memberships and that the correct Transport Attribute is used.