VanDyke Software Forums - ConnectInTab is preventing further session changes

VanDyke Software Forums (https://forums.vandyke.com/index.php)

- Scripting (https://forums.vandyke.com/forumdisplay.php?f=14)

- - ConnectInTab is preventing further session changes (https://forums.vandyke.com/showthread.php?t=14490)

ConnectInTab is preventing further session changes

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.

Code:

        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.

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).

Quote:

Originally Posted by bgagnon (Post 54868)

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.

Code:

#$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

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.

Quote:

Originally Posted by bgagnon (Post 54874)

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.

https://forums.vandyke.com/attachmen...achmentid=2111

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.

Hi oliver366370,

Quote:

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.

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

Hi Oliver,

Sorry, I am checking ...

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.

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.

Code:

    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.

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