I am using angular
Lets say i have login screen(model,controller,view) and few other screens (model,controller,view) that perform some secret manipulation that available only to logged in user.
Is this possible to load to browser only login files(That those files won't be shown in F12/sources) ,then when user successfully logged in load all the secret files.
In short i don't want that user can see those files before he logged in.
That is one of the problems within client-side applications like angular SPAs. Since you want to load the content from your server, IF something happens on the client, the client already has to know, where it can get the content.
One solution could be to us ui-router. (Documentation). There, you can set a state for logged in users. Every state can have an own html template, which gets loaded, when you enter the state.
The problem ist, that the path of said html template is already on the client. That means, you have to set some kind of cookie from your server, so that you know, that the client is logged in. And only then, the requested template can be recieved. That way everybody can know where the template is on your server but cannot access it.
Related
I have an angularjs app with ASP.NET WebAPI2 REST APIs. There is a scenario where I have a display a popup for initiating a survey for end users (both authenticated and anonymous types). On clicking the popup options, the user will be redirected to another applicaiton which captures all the responses provided by the user.
There is no relation between the angularjs app and the survey application.
Now next time if the user revisits the application then in that case based on the previous action taken to fill the survey , I have to take a decision to display or hide the popup for the user.
I thought of cookies and localStorage as the options but I think are not ideal choices for this scenario.
Can anyone help me to know are there any other possible options to handle this scenario?
You can solve this using the redirection link.
For example if he finished correctly the Survey you will redirect him to:
www.myapp.com/survey/success
Than in the App you can do something like: get the URL parameters, if the parameters is success store it on localStorage so next time he revisits the web-page the Popup wont show.
Otherwise direct him to:
www.myapp.com/survey/
I think the best option here is to save this information in the database using your ASP.NET WebAPI2 REST APIs. In the moment that the end user clicks the survey you can also make an Api call which will save in the database info about user's action(this will probably be sth you can do for authenticated users). For not authenticated users you can just save that information in localStorage in the moment they are clicking the survey.
MDN docs state:
To enable a web page to contain an <img> element whose src attribute points to this image,
you could specify "web_accessible_resources" like this:
"web_accessible_resources": ["images/my-image.png"]
The file will then be available using a URL like:
moz-extension://<extension-UUID>/images/my-image.png"
<extension-UUID> is not your extension's ID.
It is randomly generated for every browser instance.
This prevents websites from fingerprinting a browser by examining
the extensions it has installed.
So, I would think that these resources cannot be read by any web page outside the extension, since they would need to know the random UUID.
However, the same MDN docs also state:
Note that if you make a page web-accessible, then any website may then link or redirect
to that page. The page should then treat any input (POST data, for examples)
as if it came from an untrusted source, just as a normal web page should.
I don't understand how "any website may then link or redirect to that page". Wouldn't it need to know the random UUID? How else could a webpage access this resource?
The point of Web Accessible Resources is to be able to include them in a web context.
While you can communicate the random UUID to the webpage so that it can use the file, it doesn't have to be included by the website code itself. Here's a hypothetical scenario:
You're writing an extension that adds a button to evil.com site's UI. That button is supposed to have an image on it.
You bundle the image with your extension, but to add it as src or CSS property to the webpage you need to be able to reference it from a web context.
So, you make it web-accessible, and then inject your UI element with a content script.
Perfectly plausible scenario.
Note that a random third-party site villains-united.com can't just scrape the URL to know if your extension is installed, since the URL is per-browser unique. This is the intent behind WebExtensions's UUID over Chrome's extension-id model.
However, let's continue our hypothetical scenario, from a security perspective.
The operators of evil.com are unhappy with your extra UI. They add a script to their code that looks for added buttons.
That script can see the DOM properties of the button, including the address of the image. Now evil.com's code can see your UUID.
Being the good guy, your extension's source code is available somewhere, including the page that launches nuclear missiles if called (why you would have that and why it would be web-accessible is another matter, perhaps to provide the functionality to good-guys-last-resort.org).
evil.com's script now can reconstruct the URL of this trigger page and XHR it, plunging the planet into nuclear apocalypse. Oops. You probably should've checked the origin of that request.
Basically, if a web-accessible resource is used in a page, the UUID likely leaks to that page's context via DOM. That may not be a page you control.
I want to show different views based on the user of my application for example if the user is admin he can see all the controls or when it is acting as user he can only see a subset of controls and UI and he can perform the limited action.
One solution that comes to my mind is sending the role information with the page as a JSON but that would require me to have knowledge of the logged in user so, basically I can first check if the user is logged in or not through the cookie? if no I can just load the lightweight version of the login page and after user logs in then I can send a new page altogether with user's profile information embedded in it.
The other approach that I see is that I can bootstrap my angular application and then check the login status and if the login is done, then bring the profile information through a JSON and update the view, but I think it would be slow and error-prone.
I don't know what is best / recommended approach.
First approach seems to be a better approach out of these 2.
Problem with the second approach is you are sending 2 requests to the server - one for login and then 2nd one to get the user role/profile. If you are choosing this approach then you may have few issues depending how are you going to implement it:
If you are updating your UI after login then you will have to decide what should be shown to the user since you don't know the user profile yet. Even if you come up with some minimal privilege UI, there will be another request to get the profile which will kind of refresh the UI again - 2 UI refreshes could be annoying for the user. Not to mention that there 2 requests going which could make your site slow.
If you decide not to update the UI after login but only after you get user profile, still the delay would be more as you will have to wait for response of 2 separate requests. Could be a major issue with slow networks(consider mobile)
If you are using the first approach, you'll get away with above mentioned problems.
I'm implementing an application using the full MEAN stack.
I created a login page to signup with facebook to be able to show a profile page. But I discovered some problems. For this reason, I created a smaller version of my webapp, maintaining the same project structure.
The complete code, executable (only replacing "client id" and "secret") with "npm install" and after "nodemon" is available here: https://github.com/Ks89/MEAN-OAuth_Example
If I'll call (with a browser) the rest API that I created to login with facebook at "http://localhost:3000/api/auth/facebook", everything will be ok!
But if I'll want to do the same thing, clicking on the "Login" button, I'll receive the error as in figure:
I know that the problem is related to CORS, but how can I'll fix this in my application, maintaining the same project structure?
I don't want to put the "rest path" inside the HTML. I tried for many days different solutions without success.
If you want, experiment directly on my application that I created exactly to write this question ;).
If really necessary, I'll able to post the entire source code here, but I prefer an organized and executable code into a repository for this particular question.
Please, give me some ideas and hopefully a solution, because I'm really blocked.
The example routes from the passport-facebook repo are intended for multipage apps, not ajax requests. If you look at what those routes are doing, /auth/facebook is just a redirect to Facebook where the user is expected to log in if necessary and authorize your application. When you make that same request from angular, it follows the redirect and tries to load the Facebook page, but the browser blocks you as your console screenshot shows. CORS would be relevant if Facebook wanted to allow you to request their login form across origins, but they don't because that would basically make you a phisher.
It looks like you're trying to handle authentication without leaving the page, but at some point you're going to need the user to leave your site and be redirected to Facebook in order to complete the OAuth flow. You can either open a pop-up containing the Facebook OAuth dialog (it looks like this is what the Facebook JavaScript SDK does by default) or just use your app's current tab with something as simple as <a ng-href="{{facebookOauthUrl}}">Log in with Facebook</a>.
I'm facing a problem don't know how to solve. I would like to get some light here.
Given an AngularJS application that routes using the standard $routerProvider, and considering the fact that whenever an end user tries to access a private area he gets redirected to the register area, happens the following:
User just landed onto de application (didn't get logged in).
User goes to /profile
The application checks whether there is session info in the client or not.
The application redirects to /profile/register
User clicks on "Back" button of the browser and goes to /profile.
(Next step is number 3 again and again).
This happens because each time the application redirects using the $routerProvider, it pushes all routes in the browser history.
My question is, how can I jump the failed /profile access over the browser history? How can I tell the browser do not save this route under given conditions
like the user is logged in?
FAQ regarding history: https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Manipulating_the_browser_history
Supposing you're using the $location built-in service to redirect, you can use $location.replace() to replace the current history entry:
if (notLoggedIn) {
$location.url( "/profile/register" );
$location.replace();
}
Note that this will apply to current digest only, as noted in the API docs.