Sarge Posted February 1, 2018 Report Share Posted February 1, 2018 Hiya, Not sure if this is possible, I believe it maybe possible already but my WebAPI-fu is too limited, but it would be nice to pass a "reason" through the WebAPI headers.EG: $ExecutePwdStateIPACall = Invoke-Restmethod -Method GET -Uri $PwdStateIPAURL -Header @{ "APIKey" = "abcdefg1234567hijklm89101112" , "Reason" = "Script Name: List of VMs"} The 'reason' would then be added to the auditing data description of WebAPI connections. Making it easier to see at a glance why a connection was made and if it was expected. In the below screenshot I have a few entries, all of which are from the same IP address for the same password, I expect to see this - but I'd like to be able to tell which script it was that made the connection - as this host runs about a dozen scripts per day all with repeating schedules every few hours (in one case, every 5 minutes...which is how I came across this enhancement request because it appears to not running anymore lol) Link to comment Share on other sites More sharing options...
support Posted February 1, 2018 Report Share Posted February 1, 2018 Hi Sarge, Sorry, this not currently possible, but we could look at it for a future build. Regards Click Studios Link to comment Share on other sites More sharing options...
Buckit Posted February 1, 2018 Report Share Posted February 1, 2018 I'd like to second Sarge's request. Great idea for the future! Link to comment Share on other sites More sharing options...
Azkabahn Posted April 4, 2018 Report Share Posted April 4, 2018 +1 point to this as well. This is related to what i just recently posted Link to comment Share on other sites More sharing options...
support Posted April 4, 2018 Report Share Posted April 4, 2018 Thanks Link to comment Share on other sites More sharing options...
Sarge Posted July 12, 2018 Author Report Share Posted July 12, 2018 I believe this is a +3 Link to comment Share on other sites More sharing options...
support Posted July 26, 2018 Report Share Posted July 26, 2018 Coming in the next release Link to comment Share on other sites More sharing options...
Sarge Posted August 8, 2018 Author Report Share Posted August 8, 2018 On 7/26/2018 at 11:10 AM, support said: Coming in the next release And now to be annoying. Can it be set on a per password list setting as a requirement? IE: No reason provided, then data isn't returned. I should have included that request earlier lol Link to comment Share on other sites More sharing options...
support Posted August 8, 2018 Report Share Posted August 8, 2018 Hi Sarge, We believe in the software industry this is called "scope creep" If we were to add this as a standard setting on the 'Password List Details' tab, then it will be quite a bit of work - as settings can be cloned from other Password Lists, and Templates, the API would need to provide cater for this also when adding Password Lists, cloning folders would need to be updated, etc, etc. Instead, what if we added this as a option on the screen below? it's the logical place to put it, but would not require all the work mentioned above, as the API Tab settings here do not get "cloned" from anywhere. Regards Click Studios Link to comment Share on other sites More sharing options...
Sarge Posted August 8, 2018 Author Report Share Posted August 8, 2018 3 hours ago, support said: We believe in the software industry this is called "scope creep" Happens to us as well, isn’t it great lol 3 hours ago, support said: Instead, what if we added this as a option on the screen below? it's the logical place to put it, but would not require all the work mentioned above, as the API Tab settings here do not get "cloned" from anywhere. That’s actualky the spot I was thinking when I was writing the post. I agree it’s most logical there. Link to comment Share on other sites More sharing options...
support Posted August 9, 2018 Report Share Posted August 9, 2018 Just thought of something for this Sarge. Let's say one Password List is configured where 'Reason' is mandatory, and we are searching across all Password Lists without a reason being specified. Do you think we should raise an exception, and break the API Call, or simply not return any records from that one Password List. Not returning records may cause some confusion for customers, but these are the only two possibilities I can think of. Thoughts? Regards Click Studios Link to comment Share on other sites More sharing options...
Sarge Posted August 10, 2018 Author Report Share Posted August 10, 2018 22 hours ago, support said: Let's say one Password List is configured where 'Reason' is mandatory, and we are searching across all Password Lists without a reason being specified. Do you think we should raise an exception, and break the API Call, or simply not return any records from that one Password List. Not returning records may cause some confusion for customers, but these are the only two possibilities I can think of. I hadn't thought of that; but I think breaking the API call maybe the best option; with an exception message similar to "One or more targeted password lists require auditing data". Confusing the customers should be avoided. As long as the exception message is clear why the API call failed then I see no issues with it. Perhaps return the password list ID(s) that the API call failed on in the exception message. Also, log the API call exception in the password list auditing data table? Link to comment Share on other sites More sharing options...
support Posted August 20, 2018 Report Share Posted August 20, 2018 One more question on this Sarge. We're also adding in new methods to manage permissions on Folders, Password Lists and Password records - see below. If this 'Mandatory Reason' option is set at the Password List level, do you think it should also be required for the new 'Permission' methods as well? Regards Click Studios Link to comment Share on other sites More sharing options...
support Posted August 21, 2018 Report Share Posted August 21, 2018 Hi Sarge, For now, we are going to make this consistent with how the UI works i.e. the Mandatory option is not applicable for managing permissions. You can still provide a reason, and it will be added to auditing data, but it's not mandatory for now. Regards Click Studios Link to comment Share on other sites More sharing options...
support Posted August 24, 2018 Report Share Posted August 24, 2018 Hello Sarge, Just letting you know this feature request is now complete, as of build 8449 released today Regards Click Studios Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.