parrishk

Good morning, Thank you for getting back to me so quickly. I also did some testing on my end and found that the URL used for generating the QR code can be a little sensitive. For example, I had to make sure I was using "%26" rather than "&" when declaring the "issuer" property. I am not sure how you generate the QR code but in my example below I used the chart.googleapis.com API. The following URL generates the QR and I verified on IOS and Windows that the Title is present and the OTP code works (after swapping out for the correct secret of course). Please let me know if you have the same result when scanning the QR code. https://chart.googleapis.com/chart?cht=qr&chs=400x400&chl=otpauth://totp/Passwordstate-marvel-ironman?secret=U2AF55TF234G2LDT%26issuer=PasswordState

Good morning, I just wanted to follow up on this. Did you ever have a chance to look into this? From what it look like, you simply need to append the following to the URI before it is converted to a QR code: "issuer=PasswordState" Example: otpauth://totp/Example:alice@google.com?secret=JBSWY3DPEHPK3PXP&issuer=Example Thanks!

Are you trying to access via https://passwordstate:9119 internal to your network or from the Internet? It will not work with just https://passowrdstate:9119 if not on the same network. As far as I know it should work fine when on the internal network... Can other mobile devices access it with just the name?

+1 for us as well. This is really the only thing preventing us from using the mobile features of Passwordstate. Looking forward to v8!

As Support said this looks like an issue with the IIS bindings. If the hostname you are trying to access the server with (MyPersonalPasswordState.com) is not in the list of bindings on IIS (Passwordstate01) it will throw that error. You can add the desired hostname through IIS as seen below.

Thank you GeoffO!!

Thank you for getting back to me on this. I believe we have already narrowed down the ports that were needed. Pretty sure it was everything on this list :-)

Good morning, Just checking in to see if you guys are able to provide any information on this. Thank you!

Good morning, We have actually already disabled the mobile site due to it not allowing two-factor auth. This seems a little counter-productive to me. Using the main site requires two-factor auth but appending /mobile to the end or using a mobile browser only required one form of auth...Unfortunately, this does not meet our needs so we will be keeping an eye out for what is to come with Version 8. It would be nice to have the ability to place Passwordstate in the DMZ just for web access and keep the production server in the internal network. There are many instances where we are unable to access our internal passwordstate server when we are connected to client VPN's. Thank you for the feedback.

Hello, The only reason we have moved it to the DMZ was to access it from the Internet. I heard about the mobile client but assumed it was for mobile devices. Will this work for normal devices too? Does the mobile site need to be enabled for this to work? We have decided not to enable the "mobile site" at this time because we want to be able to utilize dual-factor authentication. Currently, it looks that it only requires one form of auth. If this mobile client can be used for this purpose that would be excellent!

If we were to place Passwordstate in the DMZ for accessing via the Internet could we also have an installation on our internal network to utilize host scanning and password discovery features without needing a second/site license?

Hello, Do you have a list of required ports for Passwordstate to communicate with Active Directory, SQL, Etc.? We have moved our Passwordstate server to our DMZ and have had a fun time trying to find all of the ports that it is trying to use. I can't find anything in the documentation. THanks!

I guess I should go ahead and acknowledge the "THERE IS AN UPDATE AVAILABLE" message now :-) Thanks for clarifying this. I will run the update and test it out. Thanks again!

Great! Thanks.

Good morning, I have just discovered the "Scheduled Reports" feature and will get some great use out of it. My request is that there be a way to manually run one of these reports for testing or other reasons that may require a report ran at that time. For example, I have created a report to email a list of expiring passwords for the month that will be sent out the first of each month. I would like to be able to run that report now to verify it works and to also get an accurate list of expiring passwords at any given time. Is this already available or am I missing it? Thank you.