I'm using Quamotion and Pester to test my mobile app.
Right now, I find myself having to repeat a lot of parameters (such as usernames and passwords) which I use in my tests.
Is there any way to use global variables in Quamotion/Pester tests?
You define global variables in Pester by prefixing them with $script:. Global variables are normally defined at the top of your script.
For example, here's a test which logs in to your app and stores the username as a variable:
$script:username = "myuser"
Describe "My App" {
it "Login" {
$usernameTextField = Find-Element -xpath "//XCUIElementTypeTextField[#name='username']"
Set-Value -elementId $usernameTextField -value $script:username
$loginButton = Find-Element -xpath "//XCUIElementTypeButton[#name='Login']"
Click-Element -elementId $loginButton
}
}
Hope it helps!
Related
I am on Windows 10 using Strawberry Perl version 5.30 and trying to print out the values of the Registry key HKEY_CLASSES_ROOT/Directory/Background/shell/WSL using the Perl module Win32::TieRegistry. Here is a screen shot from the Registry Editor app in Windows 10:
I am using this Perl script to print the value:
use feature qw(say);
use warnings;
use strict;
use Data::Dumper qw(Dumper);
use Win32::TieRegistry( Delimiter=>"/", ArrayValues=>0 );
{
dump_keys("HKEY_CLASSES_ROOT/Directory/Background/shell/WSL");
dump_keys("HKEY_CLASSES_ROOT/Directory/Background/shell/AnyCode");
}
sub dump_keys {
my ($key) = #_;
say "Dumping keys for $key:";
my $tree= $Registry->{$key};
my #keys = keys %$tree;
print Dumper(\#keys);
}
The output is (running from a CMD terminal with adminstration privileges):
>perl p.pl
Dumping keys for HKEY_CLASSES_ROOT/Directory/Background/shell/WSL:
$VAR1 = [];
Dumping keys for HKEY_CLASSES_ROOT/Directory/Background/shell/AnyCode:
$VAR1 = [
'command/',
'/'
];
as seen it prints the AnyCode subkey but not the WSL subkey. I also checked with running reg query from the same CMD:
>reg query HKEY_CLASSES_ROOT\Directory\Background\shell\WSL
HKEY_CLASSES_ROOT\Directory\Background\shell\WSL
(Default) REG_SZ #wsl.exe,-2
Extended REG_SZ
NoWorkingDirectory REG_SZ
So that works fine, but why doesn't the Perl script print the value of the WSL subkey?
It turns out that even if you run the Perl script as admin, you do not necessarily have write access to a given registry key, see this blog post for more information.
According to the documentation for Win32::TieRegistry, the default $Registry (the tied hash exported by Win32::TieRegistry) is opened with both read and write access:
The virtual root of the Registry pretends it was opened with access
KEY_READ()|KEY_WRITE() so this is the default access when opening keys
directory via $Registry
This explains why some keys cannot be accessed from $Registry since it when accessing a key the write permission is required.
As explained in the blog post it is possible to grant yourself write access to any key in the registry by using the regedit app in Windows 10.
Another approach is to only require read access (not write access) when opening a tied hash with Win32::TieRegistry:
use feature qw(say);
use warnings;
use strict;
use Data::Dumper qw(Dumper);
use Win32::RunAsAdmin qw(force);
use Win32API::Registry qw(regLastError KEY_READ);
use Win32::TieRegistry( Delimiter=>"/", ArrayValues=>0 );
{
my $reg = $Registry->Open("HKEY_CLASSES_ROOT/Directory",
{ Access=>KEY_READ(), Delimiter=>"/" }
);
dump_keys($reg, "Background/shell/WSL");
dump_keys($reg, "Background/shell/AnyCode");
}
sub dump_keys {
my ($reg, $key) = #_;
my $tree= $reg->{$key};
if (!$tree) {
say "failed: $^E";
}
else {
my #keys = keys %$tree;
print Dumper(\#keys);
}
}
I am using PowerShell Pro Tools to create a GUI application that consists of all the common scripts I would run on a clients server:
main.ps1
main.ps1 loads a ServerConnection form on load:
The code behind this is pretty basic, it just gets the database name and server address for an SQL server:
$btnConfirm_Click = {
$ServerConnectForm.Close();
}
$btnTest_Click = {
## Set database connection variables [global]
$Global:databaseName = $cmbDatabaseName.Text;
$Global:serverAddress = $txtServerAddress.Text;
## Check db connection
$testResult = Invoke-SqlCmd -serverInstance $serverAddress -Database $databaseName -Query "SELECT TOP 1 SettingName FROM Settings";
## Write results to user
if ( $testResult -ne $null ) {
$lblTestResult.ForeColor = "#2acc18";
$lblTestResult.Text = "Test connection successfull";
<# If test connection success enable confirm button #>
$btnConfirm.Enabled = $true;
}
else {
$lblTestResult.ForeColor = "#d61111";
$lblTestResult.Text = "Test connection failed";
}
}
$txtServerAddress_Leave = {
## Get TRIS database list
$databaseList = Invoke-Sqlcmd -ServerInstance $txtServerAddress.Text -Query "
SELECT name FROM sys.databases WHERE CASE WHEN state_desc = 'ONLINE' THEN OBJECT_ID(QUOTENAME(name) + '.[dbo].[settings]', 'U') END IS NOT NULL
"
## Clear combo box
$cmbDatabaseName.Items.Clear();
## Add to combo box
foreach ($database in $databaseList) {
$cmbDatabaseName.Items.Add($database.ItemArray[0]);
}
}
. (Join-Path $PSScriptRoot 'main.designer.ps1')
$MainForm.ShowDialog()
The problem is that when I either compile this into an executable or run main.ps1 directly from the project folder, none of the code outside of main.ps1 works. The form will show up but I cannot find a way to get the code behind the form to work. For example in the ServerConnection form, adding a server address does not populate the database names and the test connection button does nothing.
Running from within Visual Studio works as intended.
Any help on this would be greatly appreciated.
EDIT :: Show the server connection form call in main.ps1
MainForm_Load
$MainForm_Load = {
## Launch server connection form
. (Join-Path $PSScriptRoot 'ServerConnect.designer.ps1');
$ServerConnectForm.ShowDialog();
## Call prereq analysis
PrereqAnalysis
}
It might be an issue with the scoping of your code.
If code outside the current scope of a session depends on said session, it will not work.
You could try setting the scope of variables and functions to global while you troubleshoot to see if it makes a difference, then change it back until you find where the scope goes wrong.
Microsoft have a good MSDoc page about Powershell scopes
Starting premise: very restrictive environment, Windows 7 SP1, Powershell 3.0. Limited or no possibility of using external libraries.
I'm trying to re-write a bash tool I created previously, this time using PowerShell. In bash I implemented autocompletion to make the tool more user friendly and I want to do the same thing for the PowerShell version.
The bash version worked like this:
./launcher <Tab> => ./launcher test (or dev, prod, etc.)
./launcher test <Tab> => ./launcher test app1 (or app2, app3, etc.)
./launcher test app1 <Tab> => ./launcher test app1 command1 (or command2, command3, etc.).
As you can see, everything was dynamic. The list of environments was dynamic, the list of application was dynamic, depending on the environment selected, the list of commands was also dynamic.
The problem is with the test → application connection. I want to show the correct application based on the environment already selected by the user.
Using PowerShell's DynamicParam I can get a dynamic list of environments based on a folder listing. I can't however (or at least I haven't found out how to) do another folder listing but this time using a variable based on the existing user selection.
Current code:
function ParameterCompletion {
$RuntimeParameterDictionary = New-Object Management.Automation.RuntimeDefinedParameterDictionary
# Block 1.
$AttributeCollection = New-Object Collections.ObjectModel.Collection[System.Attribute]
$ParameterName = "Environment1"
$ParameterAttribute = New-Object Management.Automation.ParameterAttribute
$ParameterAttribute.Mandatory = $true
$ParameterAttribute.Position = 1
$AttributeCollection.Add($ParameterAttribute)
# End of block 1.
$parameterValues = $(Get-ChildItem -Path ".\configurations" -Directory | Select-Object -ExpandProperty Name)
$ValidateSetAttribute = New-Object Management.Automation.ValidateSetAttribute($parameterValues)
$AttributeCollection.Add($ValidateSetAttribute)
$RuntimeParameter = New-Object Management.Automation.RuntimeDefinedParameter($ParameterName, [string], $AttributeCollection)
$RuntimeParameterDictionary.Add($ParameterName, $RuntimeParameter)
# Block 2: same thing as in block 1 just with 2 at the end of variables.
# Problem section: how can I change this line to include ".\configurations\${myVar}"?
# And what's the magic incantation to fill $myVar with the info I need?
$parameterValues2 = $(Get-ChildItem -Path ".\configurations" -Directory | Select-Object -ExpandProperty Name)
$ValidateSetAttribute2 = New-Object Management.Automation.ValidateSetAttribute($parameterValues2)
$AttributeCollection2.Add($ValidateSetAttribute2)
$RuntimeParameter2 = New-Object
Management.Automation.RuntimeDefinedParameter($ParameterName2, [string], $AttributeCollection2)
$RuntimeParameterDictionary.Add($ParameterName2, $RuntimeParameter2)
return $RuntimeParameterDictionary
}
function App {
[CmdletBinding()]
Param()
DynamicParam {
return ParameterCompletion "Environment1"
}
Begin {
$Environment = $PsBoundParameters["Environment1"]
}
Process {
}
}
I would recommend using argument completers, which are semi-exposed in PowerShell 3 and 4, and fully exposed in version 5.0 and higher. For v3 and v4, the underlying functionality is there, but you have to override the TabExpansion2 built-in function to use them. That's OK for your own session, but it's generally frowned upon to distribute tools that do that to other people's sessions (imagine if everyone tried to override that function). A PowerShell team member has a module that does this for you called TabExpansionPlusPlus. I know I said overriding TabExpansion2 was bad, but it's OK if this module does it :)
When I needed to support versions 3 and 4, I would distribute my commands in modules, and have the modules check for the existence of the 'Register-ArgumentCompleter' command, which is a cmdlet in v5+ and is a function if you have the TE++ module. If the module found it, it would register any completer(s), and if it didn't, it would notify the user that argument completion wouldn't work unless they got the TabExpansionPlusPlus module.
Assuming you have the TE++ module or PSv5+, I think this should get you on the right track:
function launcher {
[CmdletBinding()]
param(
[string] $Environment1,
[string] $Environment2,
[string] $Environment3
)
$PSBoundParameters
}
1..3 | ForEach-Object {
Register-ArgumentCompleter -CommandName launcher -ParameterName "Environment${_}" -ScriptBlock {
param($commandName, $parameterName, $wordToComplete, $commandAst, $fakeBoundParameter)
$PathParts = $fakeBoundParameter.Keys | where { $_ -like 'Environment*' } | sort | ForEach-Object {
$fakeBoundParameter[$_]
}
Get-ChildItem -Path ".\configurations\$($PathParts -join '\')" -Directory -ErrorAction SilentlyContinue | select -ExpandProperty Name | where { $_ -like "${wordToComplete}*" } | ForEach-Object {
New-Object System.Management.Automation.CompletionResult (
$_,
$_,
'ParameterValue',
$_
)
}
}
}
For this to work, your current working directory will need a 'configurations' directory contained in it, and you'll need at least three levels of subdirectories (reading through your example, it looked like you were going to enumerate a directory, and you would go deeper into that structure as parameters were added). The enumerating of the directory isn't very smart right now, and you can fool it pretty easy if you just skip a parameter, e.g., launcher -Environment3 <TAB> would try to give you completions for the first sub directory.
This works if you will always have three parameters available. If you need a variable # of parameters, you could still use completers, but it might get a little trickier.
The biggest downside would be that you'd still have to validate the users' input since completers are basically just suggestions, and users don't have to use those suggestions.
If you want to use dynamic parameters, it gets pretty crazy. There may be a better way, but I've never been able to see the value of dynamic parameters at the commandline without using reflection, and at that point you're using functionality that could change at the next release (the members usually aren't public for a reason). It's tempting to try to use $MyInvocation inside the DynamicParam {} block, but it's not populated at the time the user is typing the command into the commandline, and it only shows one line of the command anyway without using reflection.
The below was tested on PowerShell 5.1, so I can't guarantee that any other version has these exact same class members (it's based off of something I first saw Garrett Serack do). Like the previous example, it depends on a .\configurations folder in the current working directory (if there isn't one, you won't see any -Environment parameters).
function badlauncher {
[CmdletBinding()]
param()
DynamicParam {
#region Get the arguments
# In it's current form, this will ignore parameter names, e.g., '-ParameterName ParameterValue' would ignore '-ParameterName',
# and only 'ParameterValue' would be in $UnboundArgs
$BindingFlags = [System.Reflection.BindingFlags] 'Instance, NonPublic, Public'
$Context = $PSCmdlet.GetType().GetProperty('Context', $BindingFlags).GetValue($PSCmdlet)
$CurrentCommandProcessor = $Context.GetType().GetProperty('CurrentCommandProcessor', $BindingFlags).GetValue($Context)
$ParameterBinder = $CurrentCommandProcessor.GetType().GetProperty('CmdletParameterBinderController', $BindingFlags).GetValue($CurrentCommandProcessor)
$UnboundArgs = #($ParameterBinder.GetType().GetProperty('UnboundArguments', $BindingFlags).GetValue($ParameterBinder) | where { $_ } | ForEach-Object {
try {
if (-not $_.GetType().GetProperty('ParameterNameSpecified', $BindingFlags).GetValue($_)) {
$_.GetType().GetProperty('ArgumentValue', $BindingFlags).GetValue($_)
}
}
catch {
# Don't do anything??
}
})
#endregion
$ParamDictionary = New-Object System.Management.Automation.RuntimeDefinedParameterDictionary
# Create an Environment parameter for each argument specified, plus one extra as long as there
# are valid subfolders under .\configurations
for ($i = 0; $i -le $UnboundArgs.Count; $i++) {
$ParameterName = "Environment$($i + 1)"
$ParamAttributes = New-Object System.Collections.ObjectModel.Collection[System.Attribute]
$ParamAttributes.Add((New-Object Parameter))
$ParamAttributes[0].Position = $i
# Build the path that will be enumerated based on previous arguments
$PathSb = New-Object System.Text.StringBuilder
$PathSb.Append('.\configurations\') | Out-Null
for ($j = 0; $j -lt $i; $j++) {
$PathSb.AppendFormat('{0}\', $UnboundArgs[$j]) | Out-Null
}
$ValidParameterValues = Get-ChildItem -Path $PathSb.ToString() -Directory -ErrorAction SilentlyContinue | Select-Object -ExpandProperty Name
if ($ValidParameterValues) {
$ParamAttributes.Add((New-Object ValidateSet $ValidParameterValues))
$ParamDictionary[$ParameterName] = New-Object System.Management.Automation.RuntimeDefinedParameter (
$ParameterName,
[string[]],
$ParamAttributes
)
}
}
return $ParamDictionary
}
process {
$PSBoundParameters
}
}
The cool thing about this one is that it can keep going as long as there are folders, and it automatically does parameter validation. Of course, you're breaking the laws of .NET by using reflection to get at all those private members, so I would consider this a terrible and fragile solution, no matter how fun it was to come up with.
Windows makes it difficult to create a network share with anonymous access (in other words, users who the share-hosting machine does not know about can access). The net share ShareName=C:\DesiredShareSource /GRANT:EVERYONE,FULL gives access to Everyone, but that does not include anonymous access (e.g. non-domain joined users, WITHOUT prompting credentials).
I know there's a way to do this from a GUI (https://serverfault.com/questions/272409/setting-up-an-anonymous-windows-server-2008-network-share), but is there a way changing security policies and creating anonymous network shares can be done strictly from PowerShell?
EDIT
This is what happens when I run the WMI script posted by Ansgar Wiechers. I get an exception but the share mounts successfully:
However, when I try and connect to the share from another box on the same network, I am still prompted for a username and password, as seen below:
Again, I want anonymous access (no username and password) to be set up all from command line.
Here is the exact code I am using in testingAnonShare.ps1, on a Win7 system:
$path = 'C:\Users\<REDACTED>\Desktop\Attempt'
$name = 'testinganon'
$description = 'share description'
function Get-Trustee($sid) {
$trustee = ([wmiclass]'Win32_Trustee').CreateInstance()
$trustee.SID = ([wmi]"Win32_SID.SID='$sid'").BinaryRepresentation
return $trustee
}
function New-FullAce($sid) {
$ace = ([wmiclass]'Win32_ACE').CreateInstance()
$ace.AccessMask = 2032127 # full control
$ace.AceFlags = 3 # container inherit + object inherit
$ace.AceType = 0 # access allowed
$ace.Trustee = Get-Trustee $sid
return $ace
}
$sd = ([wmiclass]'Win32_SecurityDescriptor').CreateInstance()
$sd.ControlFlags = 4
$sd.DACL = (New-FullAce 'S-1-1-0'),
(New-FullAce 'S-1-5-7')
$wmi = Get-WmiObject Win32_Share -List
$wmi.Create($path, $name, 0, $null, $description, '', $sd) | Out-Null
All examples create a share called test mapped to a path D:\test, granting full access to Anonymous and Everyone.
Windows Server 2012 R2 and newer
To create a share with everyone having Full access this is the command
New-SmbShare -Name 'test' -path 'D:\test' -FullAccess 'ANONYMOUS LOGON','Everyone'
To update an existing share to have the same permission is a little more complicated. First, assume the share name is test. Here is the code to change it to the same permissions as above.
Get-SmbShare -Name test |
Set-SmbShare -SecurityDescriptor 'O:BAG:DUD:(A;;FA;;;AN)(A;;FA;;;WD)'
To get the SecurityDescriptor string, create a share test like you want it and run the following command.
(get-smbshare -Name Test).SecurityDescriptor
Backward compatible (NET SHARE)
This can also be done with net share
net share test=D:\test /GRANT:"ANONYMOUS LOGON,FULL" /GRANT:"Everyone,FULL"
In addition to New-SmbShare (Windows Server 2012 or newer) and net share you can also use WMI for creating network shares.
$path = 'C:\DesiredShareSource'
$name = 'sharename'
$description = 'share description'
function Get-Trustee($sid) {
$trustee = ([wmiclass]'Win32_Trustee').CreateInstance()
$trustee.SID = ([wmi]"Win32_SID.SID='$sid'").BinaryRepresentation
return $trustee
}
function New-FullAce($sid) {
$ace = ([wmiclass]'Win32_ACE').CreateInstance()
$ace.AccessMask = 2032127 # full control
$ace.AceFlags = 3 # container inherit + object inherit
$ace.AceType = 0 # access allowed
$ace.Trustee = Get-Trustee $sid
return $ace
}
$sd = ([wmiclass]'Win32_SecurityDescriptor').CreateInstance()
$sd.ControlFlags = 4
$sd.DACL += (New-FullAce 'S-1-1-0').PSObject.BaseObject
$sd.DACL += (New-FullAce 'S-1-5-7').PSObject.BaseObject
$wmi = Get-WmiObject Win32_Share -List
$wmi.Create($path, $name, 0, $null, $description, '', $sd) | Out-Null
S-1-1-0 and S-1-5-7 are the well-known SIDs of the Everyone and Anonymous groups respectively.
Appending each ACE separately to the DACL property is required to make the code work with PowerShell v2. In more recent version you can assign the ACEs as an array, and you also don't need to unwrap the base object:
$sd.DACL = (New-FullAce 'S-1-1-0'), (New-FullAce 'S-1-5-7')
To actually enable anonymous access to shares you also need to make three changes to the local security policy (source):
Start secpol.msc.
Navigate to Security Settings → Local Policies → Security Options.
Change the following settings:
Accounts: Guest account status → Enabled
Network access: Let Everyone permissions apply to anonymous users → Enabled
Network access: Shares that can be accessed anonymously → sharename
Note that I did not have to change the setting Network access: Restrict anonymous access to Named Pipes and Shares to enable anonymous access from Windows 7 to an anonymous share on Server 2012 R2, but I did have to add NTFS permissions for the Everyone group.
$acl = Get-Acl -Path 'C:\DesiredShareSource'
$ace = New-Object Security.AccessControl.FileSystemAccessRule(
'Everyone', 'ReadAndExecute', 'ContainerInherit, ObjectInherit', 'None', 'Allow'
)
$acl.AddAccessRule($ace)
Get-Acl -Path 'C:\DesiredShareSource' -AclObject $acl
I'm not aware of a way to make the policy changes with a script. You may be able to cook up something by wrapping secedit in PowerShell, but whenever I had to deal with secedit it turned out to be … bothersome, so I wouldn't recommend it. In a domain environment you can deploy local security policy settings via group policies, though.
Maybe I am trying to use AWS EC2 incorrectly, please help me out. I would like to make a base ami via a user data script, this is no problem, it works. However, the next step is to make an image, however since the object is untagged its kind of a pain to filter for it, I can add criteria for region, vpc, security group and state, this would find the object and I could build the image.
However I do not want to overwrite the existing image, so ideally i need to tag this with a name and version, no problem. But then I need the child images to find that image, and i would like to find via name and version, but dynamically, i.e. latest. In docker it is pretty straight forward as long as the container is tagged, to use latest the version can be omitted and it will auto pull the latest. Is there a similar technique here? What do you guys use? Am I possibly using this wrong?
Here is what I did:
Note: although this is for is tagging an instance, it can easily be modified to work with images.
Note: I am not a powershell power user, so if you see a glaring inefficiency, please let me know.
I use Jenkins to build the machine, as such it has environment variables that I use for the tagging, however it calls a powershell script that has this signature, so you could manually call or call it via another script:
param(
...
[Parameter(Mandatory=$true)][string]$Tag_Name,
[Parameter(Mandatory=$true)][string]$Tag_Version
)
Inside of this script, I set the instance tags like so:
#Get metadata from ec2 service
$identityDocument = (Invoke-WebRequest http://169.254.169.254/latest/dynamic/instance-identity/document/).Content | ConvertFrom-Json
$tags = #(
#{Key = "Name"; Value = $Tag_Name},
#{Key = "Version"; Value = $Tag_Version}
)
New-EC2Tag -Resource $identityDocument.instanceId -Tag $tags
In another script, I can query by name, find all instances, parse the result into a hash table of [InstanceId, Version], sort by Version and get the top one.
$instanceName = "hello-world"
$instances = GetHashTableOfFilteredInstances $instanceName
$instanceId = GetNewestInstance($instances)
Write-Host 'Information for ' $instanceName
Write-Host '================='
Write-Host 'The newest instance is ' $instanceId
Write-Host '================='
function GetHashTableOfFilteredInstances($tagName){
$instances = Get-EC2Instance -Filter #( `
#{name='tag:Name'; values=$tagName};`
) | Select-Object -ExpandProperty instances
$actInstances= #{}
foreach($instance in $instances){
foreach($tag in $instance.Tag){
if ($tag.Key -ne "Version") {
Continue;
}
$actInstances.Add($tag.Value, $instance.InstanceId)
}
}
return $actInstances
}
function GetNewestInstance($instances){
return ($instances.GetEnumerator() | Sort-Object Key -descending)[0].Value
}