All Activity
This stream auto-updates
- Today
-
Authentication Option: Manual and ANY other Method
support replied to CLB's topic in General Support
Hi Constantin, With the user of User Account Policies, found under the Administration menu, you can have different authentication options for different sets of users. Can you investigate this, and let us know if this is what you need. Regards Click Studios -
Hi Chris, Thanks for your help, and patience, in trying to troubleshoot this, and we can confirm we see the same thing if the Password List is for a Remote Site Location. So we'll look into getting this fixed for the next release, and test all other methods as well to make sure there are no other issues. Thanks again. Regards Click Studios
-
Yes, that would work
-
Thats a lot of pages! Lets go with the custom.css for now, plus maybe a seperate one for login / log out page?
-
Thanks Sarge. Per page CSS would require us to update all 492 pages in Passwordstate, so this is unlikely to happen sorry - unless we have a lot of customers who also need this level of customization for all pages in Passwordstate. Regards Click Studios
- Yesterday
-
Found it.... We stopped with the custom CSS when we went to v8 because it become to difficult to keep verifying changes. So it would be nice to be able to get these changes back, but on a per-page basis. I understand its a lot of leg work and you've already got a lot in the pipeline for this year. /* Start Changes */ /* Changes made to adjust Logo TR to be White, while keeping existing base color specified in Admin Control Panel */ /* This ensures the logo fits the color scheme */ /* keeps the specified base color in Admin Control panel on the login and logout screens. This effectively overwrites what is set in Admin Control Panel. Ensure you update the color when you change base color in admin control panel.*/ td.BaseColor { background-color:#22428C !important; } /* sets the background color of the login and log out screens white, overwritting what we set in the admin control panel. */ body.BaseColor { background-color:white !important; } /* Hides the "Forms Based Authentication" text on the index page and the Company - Password Manager text on the loggedoutpopup.aspx page. */ div.title2 { font-size:0px !important; } /* The below changes target individual element IDs to adjust color. By default these where all white - which blended in with the Body.BaseColor change above */ #BuildDiv { color: #C0C0C0 !important; } #ActiveUsersTD { color: black !important; } #A2 { color: black !important; } #NewBuildLabel { color: #545454 !important; } #MaintenanceModeDiv { color: red !important; } #A5 { color: red !important; } #QueuedEmailsDiv a:link { color: red !important; } #QueuedEmailsDiv a:visited { color: red !important; } #PendingAccessRequestsDiv { color: black !important; } #A1 { color: black !important; } /* END Changes */
-
Yep it sure would be , however it would be my preference. There was other things we changed in the CSS on the login screens and log out screens. I'll try and find the old CSS we used as it was somewhat substantial changes, more than just BaseColor.
-
Hi there, in password lists an for web authentication its possible to specify manual ad authentication and some other factor authentication. With many users and many other options like (Google, OTP, Mail, SMS, RSA) it is sometimes not nice to handle because we have to agree on one option. It is possible to specify "Manual AD Authentication + Any other Authentication Method" so we ensure that we have a 2-Factor Authentication but it does not matter which second factor option is used? Edit: Sorry this Thread should go to 8.X Support not 7.x..... Kind regards, Constantin
-
Issues adding passwords via webapi
Chris Gribbin replied to Chris Gribbin's topic in General Support
OK it's been a long morning but I believe I have it nailed down - I created a brand new list that mirrors my ListID 30 in every single way - ID 710 - and the test was successful. I created a brand new list that mirrors those exactly except for a client remote site - and the test fails. I subsequently went hunting for other 3 digit lists under Internal site and those all succeeded, regardless of template link or permissions, and all attempts for any remote site regardless of permissions and template link failed. It just so happens that a majority of my 'internal' lists are 2 digits and the client ones are almost all 3 digits.. in fact I have one client with a 2 digit list only, and for grins I tried that one and it failed. So - not a 3 digit problem - now appearing to be a Remote Site Location Problem. I did try and add "SiteID":"4" to my json body like you use in /api/passwordlists and no luck.. I slowly read the documentation (I'm guilty of skimming most of the time) to see if there was mention of this and I didn't see it anywhere in the passwords section - I think it's implied that it should inherit site by the listID like when you add a new record in the webui.. but my new theory is that that is not working. Can anyone corroborate? Works for any list on 'Internal' Site - but not any of the lists tied to a remote site $jsonData = ' { "PasswordListID":"94", "Title": "North American Core Router 1", "UserName":"narouter1", "password":"StenS-Lun#3$2^yc", "APIKey":"putyourownglobalpapikeyhere" } ' $PasswordstateAPIURL = 'https://yourpwsinstance.com/api/passwords/' $result = Invoke-Restmethod -Method Post -Uri $PasswordstateAPIURL -ContentType "application/json" -Body $jsonData Write-Output $result #Return all properties of object(s) Remove-Variable result Cheers! -Grib -
Actually, maybe for the login screens we could change the name of the css from BaseColor to LoginScreenBaseColor, and then you can have different css for these screens as well. Also, did you know you can now also use a background image on all logins screens - this would negate the custom css on these screens if you would prefer to use that. Regards Click Studios
-
I've just done some quick testing in the main site, and this should be possible with us adding one line of code into one of our classes. So if you were to include your own css file called /App_Themes/custom.css, then this would apply to all pages in the core product. You will need to include the '!important' rule on all your css attributes so they take precedence over ours, but it seems to work nicely. If we add this in though, it would be one css file for the whole site - so if you were to change the base color, it would change for all pages, just not the login screens. Trying to provide custom css for each individual page would be a considerable amount of work. The Self Destruct and Reset Portal would be the same concept with this custom.css file. Because you add this file yourself, no upgrades will touch this. Regards Click Studios
-
Thanks Sarge
-
In the context of my post it was for the Passwordstate login screens. At one stage we were also hiding some elements on the login screens via the CSS as well as changing the headerTable to force a different background colour (thus overriding the base colour it inherits). Minimal at this stage because it becomes to difficult to verify lots of changes after each upgrade, but at this stage. Body Background, btn-info Background & Border Colour, btn-info:hover Background & Border Colour. body { padding: 3em 15px; background: #ffffff; /*background: rgb(93,101,144); Old browsers background: -moz-linear-gradient(-45deg, rgba(93,101,144,1) 0%, rgba(54,169,225,1) 100%); FF3.6-15 background: -webkit-linear-gradient(-45deg, rgba(93,101,144,1) 0%,rgba(54,169,225,1) 100%); Chrome10-25,Safari5.1-6 background: linear-gradient(135deg, rgba(93,101,144,1) 0%,rgba(54,169,225,1) 100%); W3C, IE10+, FF16+, Chrome26+, Opera12+, Safari7+ filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#5d6590', endColorstr='#36a9e1',GradientType=1 ); IE6-9 fallback on horizontal gradient */ /* display: table;*/ font-family: "Raleway", sans-serif; } .btn-info { color: #fff; background-color: #003255; border-color: #003255; } .btn-info.focus, .btn-info:focus, .btn-info:hover { background-color: #00C8C8; border-color: #00C8C8; }
-
Hi Sarge, Thanks for your request. Could you provide an example of the CSS code you are modifying here? When you refer to "Currently the base colour", are you referring to the Self Destruct or Password Reset Portal still, or the logins screens in Passwordstate? Thanks Click Studios
-
Hi Rob, If you close your Browser, and not just the tab, does that make any difference? Thanks Click Studios
-
Hi Chris, I've sent an email regarding this, and it does not have anything to do with a 3 digit PasswordListID - we need to keep investigating. Regards Click Studios
- Last week
-
Issues adding passwords via webapi
Chris Gribbin replied to Chris Gribbin's topic in General Support
Eureka! It fails going to my test list - which is ID 652 (tried 660 and a few others in that range previously) In wondering if it's the list.. common denominator and whatnot.. I tried against an internal list with ID 30 and it succeeds. More testing shows it fails on each try to a 3 digit list - I found ID 142 and it fails, but on ID 98 it succeeds. I sent an email back with more details too. Also, my script had one bug, in the $body creation I needed to change AccountType to AccountTypeID - then it worked and added all 3 good entries to list ID 30 as expected. See your North American Core Router and my 3: AllAtrib, NoType,NoUrl from the script. So it seems to me that the culprit is the 3 digit list IDs not being accepted. Wish I'd have thought of that sooner.. I honestly thought it was something simple I was doing wrong. Cheers! -Grib -
500 error when using resource 'passwordlists' (webapi)
support replied to choffmann's topic in General Support
Hello, Could you please refer to our API Documentation under the help menu - there are more parameters required when creating Password Lists. e.g. where to place it in the Navigation Tree, what permissions to apply, what settings for the Password List, etc. Regards Click Studios -
Hi Chris, We've emailed you a script we tested with which works - can you let us know how it goes for you? Regards Click Studios
-
Hello, I am unable to create password lists using passwordlists resource via webapi. I am using Powershell: $jsonData = ' { "PasswordList":"TEST LIST", "Description":"TEST" } ' $PasswordstateUrl = 'https://*passwordstate url*/winapi/passwordlists' $result = Invoke-Restmethod -Method Post -Uri $PasswordstateUrl -ContentType "application/json" -Body $jsonData -UseDefaultCredentials $PasswordListID = $result.PasswordListID Obviously I am replacing *passwordstate url* with the correct URL for my environment. Here is the exception I am getting: Invoke-Restmethod : [{"errors":[{"message":"Invalid API Call"},{"phrase":"Error = Object reference not set to an instance of an object."}]}] At line:2 char:15 + ... $result = Invoke-Restmethod -Method Post -Uri $PasswordstateUrl -Co ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebException + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand Outputting $error[0].Exception yields: The remote server returned an error: (500) Internal Server Error. My Passwordstate Build is 8501.
-
choffmann joined the community
-
Issues adding passwords via webapi
Chris Gribbin replied to Chris Gribbin's topic in General Support
Sent this to Support this morning but afterthought I'd post it here too. OK so I made a few manual calls and they still fail – this is I believe the core of the issue, and once these can get in a state where they go I can make the script work. I sanitized my Global API key and TLD out of the commands on pasting here – but they were of course in there and working for the test commands. Other than that this is a direct copy from my powershell window. …and for due diligence’s sake I ran them all manually in : · terminal on VisualStudioCode · debug on PowerShell Studio · F8 runs in ISE · 2012 RDS Terminal Server Session Powershell as admin · Colleague’s PC in-shop · Remote (my home) PC Hopefully ruling out any location / PC / Software issues – these runs all had identical results. First I used your example text from /api/#addingpassword: (adjusted my list, and removed $ from the password arbitrarily because I don’t like it..) PS H:\> Invoke-Restmethod -Method Post -Uri https://passwordstate.com/api/passwords -ContentType "application/json; charset=utf-8" -Body '{ >> "PasswordListID":"652", >> "Title":"North American Core Router 1", >> "UserName":"narouter1", >> "password":"StenS-Lun#32^yc", >> "APIKey":"" >> } >> ' Invoke-Restmethod : [{"errors":[{"message":"Invalid API Call"},{"phrase":"Error = Object reference not set to an instance of an object."}]}] At line:1 char:1 + Invoke-Restmethod -Method Post -Uri https://pws.wenetwork.com/api/pas ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebExc eption + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand Then I did the $jsonBody method with my own data: PS H:\> Invoke-Restmethod -Method Post -Uri https://passwordstate.com/api/passwords -ContentType "application/json; charset=utf-8" -Body '{ >> "UserName": "uname6", >> "Password": "pass6", >> "APIKey": "", >> "AccountType": "93", >> "PasswordlistID": "652", >> "Title": "NoUrl", >> "URL": "" >> }' Invoke-Restmethod : [{"errors":[{"message":"Invalid API Call"},{"phrase":"Error = Object reference not set to an instance of an object."}]}] At line:1 char:1 + Invoke-Restmethod -Method Post -Uri https://pws.wenetwork.com/api/pas ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebExc eption + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand Then I did the $body | ConvertTo-Json method: (changed the list ID in this one in case it was complaining about that list) PS H:\> Invoke-Restmethod -Method Post -Uri https://passwordstate.com/api/passwords -ContentType "application/json; charset=utf-8" -Body '{ >> "UserName": "uname6", >> "Password": "pass6", >> "APIKey": "", >> "AccountType": "93", >> "PasswordlistID": "660", >> "Title": "NoUrl", >> "URL": "" >> }' Invoke-Restmethod : [{"errors":[{"message":"Invalid API Call"},{"phrase":"Error = Object reference not set to an instance of an object."}]}] At line:1 char:1 + Invoke-Restmethod -Method Post -Uri https://pws.wenetwork.com/api/pas ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebExc eption + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand The only difference I see between the three are subtle spacing issues in the position of the ‘:’ - worth noting that in my VisualStudioCode it sees that colon as an unexpected character if I paste the commands into a .ps1 there, but in a .json of course it’s fine… being json data, -
Thank you. I'm on 8501 now. It does work, but there appears to be a security glitch. I only have a single public IP on the allowed list now. If I use SAML from another IP, Passwordstate correctly ignores it and presents me with forms based auth. However, if you simply close that browser tab, and try SAML again, the next time it opens up it will auth you via SAML. One of my staff brought this up. It's only presenting the alternative auth once, then if you try the default auth, it will let you use it the second time. We've tested this repeatedly. Thanks, Rob
-
Hi All, I raised this by email but thought I'd put it here to get any additional +1s. We’ve made some customisations to the CSS for the SelfDestruct portal and will be doing so to the PasswordReset Portal. Upgrades currently overwrite these customisations and require the customisations to be put back in place with each upgrade, this isn't as simple as a copy and paste, as we need to ensure nothing in the original CSS has changed that will break the customisations. It would be nice to have access to the CSS and embedded styles, and for the customisations to be remembered across upgrades. This would allow far greater flexibility in customisations and branding; and remove the need to reapply and test customisations with each upgrade. I'd suggest moving each CSS into the database, and then have a new system setting section dedicated to branding/customisations. Currently the base colour sets the page background for the login/logout screens; we'd rather have this set to a colour other than the base colour, but the only way to achieve this is to modify the CSS. This, and the ability to customise the button colours on the portals is an example of greater flexibility for the customers branding requirements that this feature request could achieve. Part of this request would be confirmation in the change log of any changes to styles that have occurred as part of the upgrade.
-
Hello, You would need to modify this directly in the database then - you can set the Managed field to 1. We can't guarantee this will work flawlessly though, as it will not preselect any Reset or Validation scripts for you. Give it a try, and let us know if you run into any issues. Regards Click Studios
-
-
-
-
API for (global) addressbook and self destruct message portal
KentF replied to Jasper's topic in Feature Requests
+ 1. It would be great to have API access for sure or a means for bulk self destruct messages with different passwords that are generated based on the policy defined (selected). When we provision new users it can be a large number and manually trying to do this is not feasible with Self Destruct. Having this capability would be great for automation and security of course.- 3 replies
-
- 1
-
-
- self destruct message portal
- addressbook
- (and 1 more)
