I am currently writing a Powershell module that I can use to control some smart light bulbs. A requirement for the API is that I provide an authorization token with each request. I currently have a cmdlet Set-AuthorizationToken that sets a $Script: scoped variable to store this token.
Currently all of the setting functionality I have created exists in the same light automation module. I would like to separate the settings logic into its own module so it can be reused.
This is where I run into trouble. To my knowledge, if I pull the settings logic into its own module then I would no longer be able to use the $Script: scope as that would be shared with any module that consumes the settings module. Additionally I would have to refactor the current settings functionality to some provide some sort of identifier so the settings module can look up the correct settings for the caller.
Is there some way that I can create the settings module so I can reuse it, but maybe load it in a manner that allows it to only know about the module that loads it? Maybe like a "library" of some sort? I would prefer not to copy the ps1 files into each module but currently that seems like the best way.
The typical way to handle this seems to be to store your credentials as an encrypted string in a file and then have a function for loading those credentials.
For example: https://github.com/RamblingCookieMonster/PSSlack/blob/master/PSSlack/Public/Get-PSSlackConfig.ps1
Related
I want to create a custom powershell module that I can distribute without exposing the code. The script includes API calls with app specific private keys that I don't want to compromise. I've seen a lot of discussions about this over the years, but nothing that really solves my problem.
Is there a good way to create a custom powershell module without exposing the underlying code? I want to be able to distribute the powershell module, for others to import or install.
this may be what you are looking for : https://www.powershellgallery.com/packages/ps2exe/1.0.11
but be careful, the API key will still be in the compiled file at someplace. You can try and cipher it, but if it's needed for your script, it will be in your file no matter how you try to hide it. the question is why do you need to ship it inside your script in the first place ? I mean that any of your script's user will be using your private key which is likely not what you want to do
I'm working with a Lenovo Thinkpad and I'm trying to set the asset tag in Powershell without using Lenovo's WinAIA.exe utility due to restrictions at work (wouldn't be able to access Windows. We would be running everything before we got into Windows Setup via Powershell), and I'm not sure how to go about this. Essentially, the property "SMBIOSAssetTag" (from the WMI class win32_SystemEnclosure) is ReadOnly, and I cannot get around this. I did triple check to make sure that Lenovo does not have its own namespace, and while using the Powershell Module "LenovoBIOS" I didn't see anything that could help me achieve this goal (unless I'm blind and totally missed it). Is there any way to go about this? I've also tried modifying the ReadOnly property of the SMBIOSAssetTag property, but I couldn't get that to work. I'd love any and all feedback. If there is any extra information needed, I'd be happy to help as well.
You don't. The property is defined as read-only in the MOF spec by design.
You're talking about writing to the SMBIOS information, which is an operation specific to your motherboard's OEM. It's up to your OEM to determine the data structure and storage method of the SMBIOS information, and the SMBIOS standard does not provide a standard write method the same way that there is a standard read method.
I'm working on a library that lets users run Node processes from inside another application. The library is called "max-api"; functions for sending data to the host application are exposed through a Node module and are loaded in the expected way:
const maxAPI = require("max-api");
However, the user never interacts with this module directly. Rather, when the host application launches the Node process, it intercepts the call to require, checks if the name of the module is "max-api", and provides the module if so.
This works great, the only issue is we have no way to provide type definitions for this modules. So, the user doesn't get any autocomplete or validation for functions in the "max-api" module. I was thinking of writing a VSCode extension to provide these, but I'm not 100% sure how to get started. Thanks in advance for any advice.
You could write a TS typings file (see Definitely Typed). This would be installed in node_modules/#types and vscode will automatically pick it up to provide code completion for your module.
I am currently working on with a solution that would be able to clone/copy/backup my existing rep:policy. 'Cause when we do some jobs it accidentally removed. I am trying to apply this kind of fix, but am failing to. It says it is an invalid path.
javax.jcr.security.AccessControlException: OakAccessControl0006: Isolated policy node. Parent is not of type [rep:AccessControllable]
final Workspace ws = session.getWorkspace();
ws.copy("/etc/commerce/products/abccompany/TvPackChannelMap/rep:policy","/tmp/nxt/TvPackChannelMap/rep:policy");
Are there other ways that I can be able to take the rep:policy thru code?
You need to make sure that your job does not touch the permissions or the rep:policy, this is the best way forward for you.
The exception could be because of /etc/commerce/products/abccompany/TvPackChannelMap/rep:policy does not exist or the user whose session you are using does not have read access to the node.
Make sure the path is correct, copy paste it to your CRX/DE to make sure it exists.
I have tried to use your code to copy a rep:policy from one node to another, works fine. But I would not* recommend copying permissions that way. The best practice is to use the Access Control Management API for all things permissions.
You can check, install and use the access control tool from netcentric. It offers a jmx interface for exporting AC entries and maybe also some APIs you could use to implement your custom solution.
The Other approach is to retrieve the ACL permissions through the query language.
For example, SELECT * FROM [rep:ACL] or SELECT * FROM [rep:ACE] where [rep:principalName] is not null should give you the results.
For more information, I would recommend you to check the ACS commons ACL Packager Implementation which is available on GitHub.
Reference Link - https://github.com/Adobe-Consulting-Services/acs-aem-commons/blob/master/bundle/src/main/java/com/adobe/acs/commons/packaging/impl/ACLPackagerServletImpl.java
I'm very new to Perl, and I have absolutely no idea how to approach this. We have an old Perl application which previously used Apache auth; we'd like to replace this with a cookie based form-style authentication. I understand that this is very case-specific, and there is no one answer as such, but some general tips would be much appreciated.
Will I need to edit all .pl files in the website? Or is there a "golden hammer" solution I can use? Is there something on CPAN I can use? We're using Perl v5.8.8 if it matters, and we're using Apache 2 shared hosting. I am happy to provide additional information as is necessary.
For the authentication to be recognized/required, it will need to be checked by the .pl file that initially receives the user's request. So the answer to whether all .pl files will need to be changed depends on how your application is structured:
If the user goes to http://myserver.com/one.pl to do the first thing and http://myserver.com/two.pl to do the second thing, then, yes, you'll need to change them all because they're all receiving requests individually.
If the user goes to http://myserver.com/dispatch.pl?mode=one for the first thing and http://myserver.com/dispatch.pl?mode=two for the second thing and dispatch.pl calls either one.pl or two.pl behind the scenes based on the mode parameter, then you only need to change dispatch.pl, since it's the only one directly receiving requests from the user.
Edited to add: If you're dealing with the first model, then I'd strongly recommend setting up an external module (.pm file) with the cookie-handling code and calling that from each of your individual .pl files instead of duplicating that code all over the place. Ideally, this would let you get by with only a few lines of added code in each .pl:
use MyCookieHandlingModule qw(verify_cookie redirect_to_login);
my $q = CGI->new; # ...unless you're already using CGI in object-oriented mode
redirect_to_login unless verify_cookie($q);
You could do it at a level outside the Perl program.
Thanks for your answers guys, but I eventually decided on CGI::Session::Auth::DBI which works well on shared hosting.