I would like to restrict the viewing of the history with one simple password authentication. What is the most simple way of doing it?
I would not like to set up multiple or indeed any chrome account. I would like to have only one history. The only needed feature is if someone would like to view the history, has to provide a password.
Thanks for your answers and tips!
The only way to achieve this I can think of is using a Chrome plugin. A quick search brought me Simple Startup Password, which asks for a password every time you start Chrome. However, I could not find a history-only protection.
I hope this still fits your needs.
Related
I'm building a website using simple passwords like 'abc123'. Chrome pops up this message everytime I log in my website and is very annoying. I can't find ways to turn it off. All solutions I searched are about removing passwords settings.
Please let me know any ways to turn this pop up off. Thank you.
The duplicate target I linked (Can I disable Chrome password check only for localhost?) only covers removing type="password" from your input elements.
As a more extreme measure, this Google support thread proposes disabling the feature browser-wide. You should consider whether this is a good solution for your other browsing habits before turning it off to improve the development experience.
To turn off this feature:
Go to Chrome settings and go to Sync and Google services.
Turn off Warn you if passwords are exposed in a data breach.
I have a chrome extension, and I am creating a website for it, that has info, and a way to test it. I would like to show the number of users currently, but have found no way to do this. It doesn't have to update every day, but if it updated weekly that would be great!
Also- I don't care if it is by a outside company rather than chrome itself. all that matters is that it works.
I am planning to show something similar on my extension's site so I have googled around a bit recently. I found a repo (https://github.com/petasittek/chrome-web-store-stats) that parses information about extensions in the Chrome Web Store. It could be useful for you. I think I will end up just parsing the Webstore page for the user numbers everyday in save it to a database. My extension is also available for Firefox and I will do the same there then aggregate the results.
I am wanting to deploy a series of MobaXterm connections (SSH connections) to our users and would like to look at creating a webpage where the users can simply invoke a chosen session by clicking on a link.
I can see that MobaXterm supports this by installing (installed by default) the URL Protocol Handler but I do not know and cannot find anywhere any syntax for the HTML links to invoke the named sessions.
Can anyone help or point me in the right direction to look please?
I found that this :
ssh localhost
allowed me to open a session, but il also created a new 'saved session' and saturated my quota so I am not sure it is the real solution.
But a least it looks like 'mobaxterm' is the protocol, if it can help anybody ending up here. This feature sure lacks documentation :)
I e-mailed Mobatek with the same question. It turns out if you right-click the "User Sessions" node and pick "Generate HTML web page", it will make a web page containing mobaxterm: protocol links to all your existing sessions. It looks like it's designed for exactly your use case, making a webpage to share with other users, so you may be able to just use that generated page as-is.
If you do want to generate your own links, it's a little trickier. I haven't really tried to understand the encoding yet; it's definitely not designed to be particularly user-readable, but since you can make any session you want and export it to a link it shouldn't be too hard to reverse-engineer the fields you care about.
Does anyone know why Box.com make it so hard to generate an authorization code programmatically? I wrote some code to do this through screen-scraping, and then recently this broke because (as far as I can tell) one HTTP request parameter changed from [root_readwrite] to root_readwrite. I was able to fix it reasonably quickly (thank you Fiddler), but why make developers go to this trouble?
Judging by the number of questions on this topic, many developers need to do this, presumably for good reason, and I don't think it can be prevented, so why not just embrace it?
Thanks for listening, Martin
The issue with doing OAuth programmatically is that it would effectively defeat the point of OAuth. Users are supposed to be presented with the Box login page so that they never have to give their username and password directly to your app. This allows users to see what permissions your app has over their account (the scope) and also allows them to revoke your app at any time.
Doing login programmatically means that at some point your app knows the user's password. This requires that the user trusts you to not do anything malicious, which usually isn't feasible unless you're a well-trusted name. The user also has to trust that you handle their credentials correctly and won't use them in an insecure way.
Box wants to encourage developers to do authentication the correct and secure way, and therefore isn't likely to support doing OAuth programmatically. You should really try to perform login the supported way by going through the Box login page.
Suppose I'm the developer of a chrome extension (which indeed I am) that is up on the web store and that I want to answer the review of one the users.
Now, if I add/edit my review my previous post gets overridden (even if I AM the developer), making my efforts in helping users useless.
Is there something I'm missing, or is it how it currently works without any way to prevent this from happening?
All reviews on the Chrome Web Store are from Google+ users now. Your best option is to click through to their profile and either send them an email, send them a message, or share a post with them. The first two are more direct and likely to get noticed but there isn't much else you can do.