ConnectInTab is preventing further session changes

[oliver366370]

Hi all,

I have a relatively simple script in VBS that catches a session pre-login and changes the credentials to match a template session in order to automate password changes across multiple random devices.
I have managed to achieve this by disconnecting the current session, then changing the config and spawning the new session in a new tab as below.

Most code has been omitted for brevity.

        crt.Session.Disconnect
        Call OSCCurrent.SetOption("Username", OSCCredential.GetOption("Username"))
        Call OSCCurrent.SetOption("Password", OSCCredential.GetOption("Password"))
        Call OSCCurrent.SetOption("Session Password Saved", true)
        Call OSCCurrent.SetOption("Use Script File", false)
        OSCCurrent.ConnectInTab
        Call OSCCurrent.SetOption("Use Script File", true)
        OSCCurrent.Save(crt.Session.Path)

It is working almost perfectly, however the issue I am having is that once the ConnectInTab method is called, the following SetOption to reenable the script afterwards is not being saved to the config file.
My guess is that the ConnectInTab method is either locking the config file so that subsequent changes are not processed, or that the connected session is constantly overwriting the config file with it's operating options. All prior changes are saved to the config file normally.

Any help to figure this out would be much appreciated.

[bgagnon]

Hi oliver366370,

How is OSCCurrent object defined?

How many connected tabs are there after you call ConnectInTab()?

It would probably be best if you posted the entire script. If there is sensitive data you don't want to post to the forums, please send a copy to support@vandyke.com and reference Attn Brenda - Forum Thread #14490 in the subject line. You can redact sensitive data but leave enough info we can determine the intent (ie: it's an IP or hostname).

[oliver366370]

Originally Posted by bgagnon

Hi oliver366370,

How is OSCCurrent object defined?

How many connected tabs are there after you call ConnectInTab()?

It would probably be best if you posted the entire script. If there is sensitive data you don't want to post to the forums, please send a copy to support@vandyke.com and reference Attn Brenda - Forum Thread #14490 in the subject line. You can redact sensitive data but leave enough info we can determine the intent (ie: it's an IP or hostname).

Hi Brenda, thanks for getting back to me so quickly.

OSCCurrent is defined by setting it to a instance of the OpenSessionConfiguration, and handing it the he current session path via crt.Session.Path.
During my testing the open session is the only one open, which is replaced with the new tabbed session as it is disconnected in script.
The script is not too long and does not contain sensitive information so I have put it below.

#$language = "VBScript"
#$interface = "1.0"

crt.Screen.Synchronous = True

Sub Main()
    If crt.Arguments.Count <> 1 Then
        crt.Dialog.MessageBox("Incorrect number of arguments")
        Exit Sub
    End If

    Dim strCredentialPath, OSCCredential, OSCCurrent
    strCredentialPath = crt.Arguments.GetArg(0)
    
    On Error Resume Next
    Set OSCCredential = crt.OpenSessionConfiguration(strCredentialPath)
    Set OSCCurrent = crt.OpenSessionConfiguration(crt.Session.Path)
    
    If (OSCCurrent.GetOption("Username") <> OSCCredential.GetOption("Username")) Or (OSCCurrent.GetOption("Password") <> OSCCredential.GetOption("Password")) Or (OSCCurrent.GetOption("Session Password Saved") <> true) Then
        crt.Session.Disconnect
        Call OSCCurrent.SetOption("Username", OSCCredential.GetOption("Username"))
        Call OSCCurrent.SetOption("Password", OSCCredential.GetOption("Password"))
        Call OSCCurrent.SetOption("Session Password Saved", true)
        Call OSCCurrent.SetOption("Use Script File", false)
        OSCCurrent.ConnectInTab
        Call OSCCurrent.SetOption("Use Script File", true)
        OSCCurrent.Save(crt.Session.Path)
    End If
    
    If Err.Number <> 0 Then
        crt.Dialog.MessageBox("An error has occured while replicating the credentials from the template session")
        'crt.Dialog.MessageBox(Err.Description)
        Exit Sub
    End If
End Sub

[bgagnon]

Hi oliver366370,

The developers are investigating the Logon script option not being enabled by the script.

We feel this feature request would be helpful in accomplishing the objective also.

I have added this thread to a feature request in our product enhancement database for the ability to run logon script prior to or without initiating the Connect process. Should a future release of SecureCRT include this feature, notification will be posted here.

If you prefer direct email notification, send an email to support@vandyke.com and include Feature Request - Forum Thread #14490 in the subject line or use this form from the support page of our website.

[oliver366370]

Originally Posted by bgagnon

Hi oliver366370,

The developers are investigating the Logon script option not being enabled by the script.

We feel this feature request would be helpful in accomplishing the objective also.

I have added this thread to a feature request in our product enhancement database for the ability to run logon script prior to or without initiating the Connect process. Should a future release of SecureCRT include this feature, notification will be posted here.

If you prefer direct email notification, send an email to support@vandyke.com and include Feature Request - Forum Thread #14490 in the subject line or use this form from the support page of our website.

Hi Brenda, thank you for looking into this for me.

Is it then fair to say that not being able to set the "Use Script File" option to true in script may be a unintentional bug and not a result of my misunderstanding of the SecureCRT object methods?
I do agree that having the option to run a script pre-connection would be incredibly useful. At the moment how I have gotten this to work, is by using the option to display login prompts on screen. This allows the script to run pre-login and complete the logic needed. Ending and restarting the session pretty well accomplished what I need to do to run the session with the new options.

The script disable and script enable options are in theory to prevent an infinite script invocation loop occurring when the script invokes a connection of the session. During testing I saw that SecureCRT seems to prevent a script running that already has an instance running. This means I should be able to effectively work around the issue by suppressing warnings on the child session invocation, however I generally wouldn't call this best practice and could cause issues down the line.
I will keep an eye out for the developers input as this is the last part that is preventing this incredibly useful script from working.

Edit: What I put down about alert suppression seems to be false. In addition through more testing I have determined that the ConnectInTab method is indeed the culprit for the following SetOption not running. If the ConnectInTab is never called then the setting of the use script option is completed successfully.
Is there any way to work around this issue? I have tried declaring the ConnectInTab as a session object and looping until connected becomes false, however this spiked the CPU to 100% while it is stuck in the loop.

[bgagnon]

Hi oliver366370,

Is it then fair to say that not being able to set the "Use Script File" option to true in script may be a unintentional bug and not a result of my misunderstanding of the SecureCRT object methods?

Yes, we believe it is changed behavior. That is why the developers are investigating. I will post here when I have further news.

[oliver366370]

Hi Brenda,

Hope you are doing well.
Has there been any updates from the investigation? Is there a workaround that can be used to spawn a new session without activating the logon script?

Kind regards,
Oliver

[bgagnon]

Hi Oliver,

Sorry, I am checking ...

[bgagnon]

Hi Oliver,

The product manager said they are still investigating the issue.

We did think there were a few more feature requests that could help you accomplish the task if they get implemented in the future.

• Credentials substitution database
• Add Sessions object to scripting API for iterating over all sessions in the Connect dialog
• Allow the user to run an alternate script, either before or after connecting to a Proxy Server (pre-connect script)

Should a future release of SecureCRT include any of these features, notification will be posted here.

If you prefer direct email notification, send an email to support@vandyke.com and include "Feature Request - Forum Thread 14490" in the subject line or use this form from the support page of our website.

[bgagnon]

Hi Oliver,

The SessionConfiguration Object Help topic is going to be updated to clarify the expected behavior.

However, the developers did suggest one change to your script that might help.

    If (OSCCurrent.GetOption("Username") <> OSCCredential.GetOption("Username")) Or (OSCCurrent.GetOption("Password") <> OSCCredential.GetOption("Password")) Or (OSCCurrent.GetOption("Session Password Saved") <> true) Then
        crt.Session.Disconnect
        OSCCurrent.SetOption "Username", OSCCredential.GetOption("Username")
        OSCCurrent.SetOption "Password", OSCCredential.GetOption("Password")
        OSCCurrent.SetOption "Session Password Saved", true
        OSCCurrent.SetOption "Use Script File", false
        OSCCurrent.Save
        OSCCurrent.ConnectInTab
        crt.Dialog.MessageBox("We are supposedly ""connected"" now.")

        Set OSCCurrent = crt.Session.Config
        OSCCurrent.SetOption "Use Script File", true
        OSCCurrent.Save
    End If

The line in red is what you would want to add.

[oliver366370]

Hi Bredna,

Apologies for the delay, I didn't have email alerts set for this thread.
The change the devs recommended has worked!
I believe a more elegant solution should be in place (for example an encrypted credential library where you can assign credential objects to the logins of an individual session).
However, in the meantime this works well as a workaround using dummy sessions.
Thank you and the devs for all your assistance!

Kind regards,
Oliver