Our web app's user account has language setting. It is vital for having some email contents sent from the server side to be translated based on that setting.
However we would like to use Angular Translate's in-built determinePreferredLanguage feature (sniffing browser's locale/language) for the login page when the logged in user's account details are not yet available for the front-end app.
Anyone has a code snippet for this?
Using determinePreferredLanguage() method was indeed the solution for this issue, but my confusion was caused by a bug in the feature itself when used in combination with fallbackLanguage() method.
This bug has been fixed: https://github.com/angular-translate/angular-translate/issues/1368
Related
I am building my first ever Chrome browser extension and I am struggling to find the right solution for handling authentication. There is a requirement that the extension stay logged in as long as possible, to reduce the need for the user to log in often. This means we would need to use Refresh Tokens. I would very much like to handle all authentication on the background script but this is no longer persistent in MV3 nor does it have access to the DOM.
This being the case, I see these options:
use Auth0 React SDK on the content scripts - this means all my authentication logic will run in a somewhat less secure environment but the token will be handled by the library and I will be able to access it in all my content and popup scripts (if I need persistence across page refreshes, I would still need to use localStorage, I believe). But this means that the background script will not have access to the token and it will need one of the other scripts to retrieve it and send it through a message
implement the Authorization Code Flow with PKCE following the steps in this tutorial on the background script - this will mean that all my auth logic is running in a more secure environment but I don't have a way of storing the token, other than using chrome.storage. It's also a bit tricky to silently retrieve the token (or check if user is still logged in) from the background script (it can be done using an injected iframe and the web_message response type or with chrome.identitybut there are still issues with the redirect_uri which needs to be listed in the Allowed Origin config of the Auth0 app - so you can only easily do this on the pages of the extension).
I know that the recommended solution for an SPA is using the SDK but I would like to know if this is also the right solution for a browser extension. Based on this article on Token Storage, localStorage is dangerous especially due to third-party scripts. Seeing that the MV3 manifest has now removed the ability to execute remote code, is localStorage an acceptable way to store tokens?
I have implemented both options using the docs provided but I am unsure as to what is the best solution, given the changes introduced by MV3.
Thank you
We have a web app which is HTML/AngularJS on the front-end and uses MS Web API on the background. We require the use of HTTPS for security reasons. Every article I've read about using plaintext passwords and how to login basically comes down to "just use HTTPS and everything will be secure".
Recently, we were testing the app in-house and the Web API service was accidentally down when the QA person was trying to login. What happened next is what you see in the image below. The password was shown in plain text in the browser. QA, my boss, the company, God and everyone in America is "having a cow" because of this.
The message being displayed in the browser isn't something I coded, it appears that it is part of AngularJS which is trying to do me a favor by showing me a failed API call and what object it was trying to pass to the API. In which case, it makes sense (I think) that Angular has that information.
Can anyone please help me understand what happened here? And what is considered the proper way to address this? I assume I can add some JavaScript code to encrypt the password on the client side first, but that also seems like it would be super easy for a hacker to intercept on the client side. So what's the correct approach to take to keep things secure on the client?
What happened is that the user (you) and the browser (on your machine) live in the same trust boundary.
You just typed that password into the browser. The browser only hides it in the input box to prevent shoulder-surfing. The browser does not really attempt to hide something you just typed in from you.
If you open dev tools in the browser, you can see anything that is sent over the wire in the HTTP protocol. Anyone outside your trust boundary cannot see this because the HTTPS protocol encrypts anything on the wire.
its hard to tell without looking on the code, but I found the similar issue :
app.config(['$qProvider', function ($qProvider) {
$qProvider.errorOnUnhandledRejections(false);
}]);
I am attempting to scrape data from one of my University's websites, which uses Shibboleth as a form of authentication/protection. However, I am having difficulty determining the best way to get past it and to the page I wish to scrape. I have valid credentials, which I could use to log in with. Does anyone have any suggestions for how to accomplish this task?
I have been working on scripting Shibbolized login with success ( in my case, to monitor the health of both the Shibboleth IdP and the applications it protects).
I am using Python's urllib module and their classes to handle the redirect following and cookie passing (for Shibboleth) and login form posting. After a little bit of tinkering urllib gets you most of the way to success with Shibbolized login. You could use this approach to handle the initial login to the Shibbolized website and then handle the scraping with a straight forward use of Python's urllib.
Example Python script for logging into Shibboleth
You could use Mechanize to submit forms and login to the website: http://wwwsearch.sourceforge.net/mechanize/
I believe that ECP profile was design to access Shibboleth protected resources by non-browser client (i.e. command line)
Try one of sample clients available on Shibboleth wiki page I linked above
You can also try Apache JMeter, just record your actions, make some scripting (well it is not so easy in terms of shibboleth), and you can access this pages automatically.
[Edit - better solution]
I believe that on Shibboleth Documentation pages are scripts for Grinder (another load testing tool). This test plans where in fact Python (ok Jython) scripts which should be quite easily modified and used for your purposes
Very late reply, but you could use Facebook Webdriver to do a login and scrape after you're authenticated.
We are trying to set up the ActiveDirectoryMemebershipProvider for an ASP.NET intranet application that is supposed to automatically sign the users into the application when it is accessed in the browser.
However the browser is sending the FQDN (MYDOMAIN\some.user) to the server and the ActiveDirectoryMemebershipProvider seems not to be able to be able to find the user based on the FQDN. However when we test the provider manually from code we found that if we try just the user name (some.user) the provider seems to be able to find the user.
Is there any setting or anything we can use to make the provider skip the domain part sent from the browser ?
Try setting atttributeMapUsername if you haven't and let me know if that works for you. When I didn't set this I had to specify my users in some.user#my.ldap.domain format.
My Web.config
<add name="MyADMembershipProvider"
type="System.Web.Security.ActiveDirectoryMembershipProvider" connectionStringName="ADConnectionString"
attributeMapUsername="sAMAccountName"
enablePasswordReset="false" maxInvalidPasswordAttempts="1" passwordAttemptWindow="15"
passwordAnswerAttemptLockoutDuration="1" minRequiredNonalphanumericCharacters="0" attributeMapEmail="mail"
/>
In IIS, go to the properties of the website and set the default domain to "\". Not sure which version of IIS you are using so if IIS resets this on you, the other way to accomplish this is to simply prepend the domain part so that it is added automatically?
Is this a custom app you are using or a product? Trying to understand why it is working from code but not from app. If you wrote the app, I assume you can change it to mimic your code. If you did not write the app, what is it? The app (such as OWA or SharePoint) may have a custom way it wants this done.
I'm working on building a Silverlight application whereas we want to be able to have a client hit a url like:
http://{client}.domain.com/
and login, where the {client} part is their business name. so for example, google's would be:
http://google.domain.com/
What I was wondering was if anyone has been able, in silverlight, to be able to use this subdomain model to make decisions on the call to the web server so that you can switch to a specific database to run a query? Unfortunately, it's something that is quite necessary for the project, as we are trying to make it easy for their employees to get their company specific information for our software.
Wouldn't it work to put the service on a specific subdomain itself, such as wcf.example.com, and then setup a cross domain policy file on the service to allow it to access it?
As long as this would work you could just load the silverlight in the proper subdomain and then pass that subdomain to your service and let it do its thing.
Some examples of this below:
Silverlight Cross Domain Services
Silverlight Cross Domain Policy Helpers
On the server side you can check the HTTP 1.1 Host header to see how the user came to your server and do the necessary customization based on that.
I think you cannot do this with Silverlight alone, I know you cannot do this without problems with Javascript, Ajax etc. . That is because a sub domain is - for security reasons - treated otherwise than a sub-page by the browsers.
What about the following idea: Insert a rewrite rule to your web server software. So if http://google.domain.com is called, the web server itself rewrites the URL to something like http://www.domain.com/google/ (or better: http://www.domain.com/customers/google/). Would that help?
Georgi:
That would help if it would be static, but alas, it's going to all be dynamic. My hope was to have 1x deployment for the application, and to use the http://google.domain.com/ idea to switch to the correct database for the user. I recall doing this once when we built an asp.net website, using the domain context to figure out what skin to use, etc.
Ates: Can you explain more about what you are saying... sounds like you are close to what I am trying to come up with. Have you seen such a tutorial for this?
The only other way I have come up with to make this work is to have a metabase that when the user logs in, it will switch them to the appropriate database as required... was just thinking as well that telling Client x to hit:
http://ClientX.domain.com/ would have been sweeter than saying to hit http://www.domain.com/ and login. It seemed as if they were to hit their name, and to show it personalized for them right from the login screen would have been much more appealing for the client base.
#Richard B: No, I can't think of any such tutorial that I've seen before. I'll try to be more verbose.
The server-side approach in more detail:
Direct *.example.com to the same IP in your DNS settings.
The backend app that handles login checks the Host HTTP header (e.g. the "HTTP_HOST" server variable in some platforms). That would contain the exact subdomain.example.com that the client used for reaching your server. Extract the subdomain part and continue...
There can also be a client-side-only approach. I don't know much about Silverlight but I'm assuming that you should be able to interface Silverlight with JavaScript. You could read document.location with JavaScript and pass it to your Silverlight applet, whereon further data fetching etc. logic would rely on the subdomain that was passed in by JavaScript.
#Ates:
That is what we did when we wrote the ASP.Net system... we pushed a slew of *.example.com hosts against the web server, and handled using the HTTP headers. The hold-up comes when dealing with WCF pushing the info between the client and the server... it can only exist in one domain...
So, for example, when you have {client}.example.com and {sandbox}.example.com, the WCF service can't be registered to both. It also cannot be registered to just *.example.com or example.com, so that's where the catch 22 is coming in at. everything else I have the prior knowledge of handling.
I recall a method by which an application can "spoof" another domain name in certain instances. I take it in this case, I would need to do such a configuration? Much to research yet I believe.