I am using ASP.Net Webapi for my back end but would like to use the AngularJS for the frontend. I did manage to get the OAuth and other security working on my ASP.Net side and on the server side I can easily check the user role using attributes like [Authorize("Admin Role")]
My question is now on the AngularJS what is the best way to give a separate start page or the chrome inside which the SPA would run.
say for e.g. i have the following flow.
user types in my site address "www.mysite.com"
I present with the login screen.
user enters the login information and submits.
Based on the user provide different base path
4.1 : for Admin "www.mysite.com/admin"
4.2 : for Operator "www.mysite.com/operator"
4.3 : for supervisor "www.mysite.com/supervisor"
what i an trying to say is, the views and data is completely different for these kind of users so I can't have one default.htm that will work for all these users and will need different shell to display the views.
I know its easy to do in MVC but not sure how to do it in AngularJS. does someone have a suggestion on how this can be done.
Related
I have a UI that needs to either show icons on a timeline view or not based on user profile. How can I show for some users and not for others? For example : the Sports Admin team needs to see the scores of all teams over time in the view (showing all years visually) but the players (when they login to the same web app) only see the timeline view with their team's performance over the years (not other details for a particular year). How can I achieve this? I am using Angular JS and javascript
I have looked into role based SSO login and show selectively and also cookies. My goal is faster performance - meaning the page needs to load fast.
I was able to find a solution for the problem above that we have been facing. After many design sessions, the best approach was to have a "User Settings" link that would save the preferences at a backend database per user id that's already captured via SSO login. The backend returns data based on the user settings as the queries to get data from backend are now made dynamic to take the selections from User Settings into account while querying the backend. As a result the front end shows data specific to user.
Tested this and seems to work perfectly without any affecting any page load performance whatsoever.
So I am using the built in ASP.NET MVC membership provider for the authorization of users in my web application. I added several fields such as first name, last name and customer number to the default fields that it comes with (email, password). I am able to register and log in users but now I want to get some of the information of the added fields for the user and use it in my AngularJS controller.
I have been working with learning AngularJS and have been successful with using the WebAPI to get and post data to the server but I am stumped on how I can get the information of the current user who is signed in to my application. I am assuming it is stored in a session token of some sort but I do not know how to access it and work with that information from an angular standpoint.
Any help is appreciated, I can provide whatever code is necessary but at this point I only have the basic built in code that asp.net uses to register and login users and my empty angular controller. Thanks.
To get the current user from anywhere on the server side, use
HttpContext.Current.User.Identity.Name;
I am currently learning Angularjs for an application that will need role-based access control logic. There are scenarios where the logic will be necessary to restrict access to certain pages based on your user role. There are other scenarios where I will have to restrict access to a section of a page or certain fields on a form based upon a users role. If Angularjs is a client side methodology, this seems to present a problem if I don't want the client to have any access to an item they aren't suppose to have access to.
What is the current approach for handling these scenarios from the server without interfering with Angularjs?
I know I have access to razor to restrict page section access but what problems would this present for Angularjs and would this be a good idea to mix razor and angular view syntax?
In my transition to Angularjs, I am having a problem wrapping my mind around how to handle this.
You can request views using ajax from MVC and handle any access restriction with a response.
I don't have good example now but it might set you in the right way?
Using knockout I have used a template enginge to retrieve partial views from MVC.
Same thing should work here and you can keep the access restriction on the server side (which you should).
One of the methods would require setting up a service to check if a user is authorized for the page (in angular), then setting params on a route
{
"/admin": {
templateUrl: 'partials/admin.html',
controller: 'AdminCtrl',
requireLogin: true//THIS
}
and then canceling navigation with in a controller by handling the $locationChangeStart event
(This is all shown in the article I posted below).
My suggestion would be to create views for each logical page element with individual controllers and handle access the same way as the example. Instead of per page, it will be per view.
In the case of adding/removing inputs from your forms, maybe there would be some way you could also handle this inside the service you created and then ng-show/hide the element depending on the access level.
A quick google search for 'Role Based Access Control in Angular' will pull up tons of useful tutorials/articles.
See This
And This
(more in-depth with the same examples)
You need to think about it in two parts:
Securing your API (ASP.NET Web API)
Using security/role information to present an appropriate UI (available options and routes, elements enabled / disabled etc. -> AngularJS)
You should assume that API clients are malicious - they aren't necessarily your application.
In terms of authentication / authorisation options: HTTP header tokens, such as JWT are a common option but HTTP only cookies are still a good option, especially if your clients are all web-based. The other advantage of JWT is that you can allow the client (AngularJS) to read the payload, and easily share information about what the user is allowed to access. If you use cookies you generally have to supply that information in another way (server side injection or API call, for example).
How your generate the token / cookie (and what they contain in terms of claims) depends how you need to authenticate people. It can be your own ASP.NET MVC login form, with credentials stored in a database if necessary.
You can use MVC views as AngularJS templates if you like, though I tend not to see many advantages beyond the layout.
I have two applications in my workspace, APP 1 and APP 2.
In my case, user will log in to APP 1. from there, i put a menu(or a link) to APP 2. however APP 2 requires authentication. So it will take me to a login page. i would like to eliminate that and get the current user's credentials on APP 1 and login to APP 2.
i'm looking for a simple straightforward method (but need to consider security) to login to APP 2.
what i could think of is apex_collection..i could store credentials n use it to create a login process for APP 2. however apex_collection is session based. eventhough i've set session for APP 2, it still wont read values from my apex_collection.
Does anyone have a suggestion or a solution?
All you need to do is use the same authentication scheme in both applications and set the cookie name attribute to the same value in both authentication schemes like this:
APEX will then use the same session across the two applications and the user will not have to log in again when they navigate from one to the other, provided of course that you pass the SESSION_ID in the URL.
A Few Comments on Default APEX Workspace Authentication Security
It may also be helpful to expand on an explanation of why the solution posted by #TonyAndrews works.
For any Apex Apps within the same workspace, if they use the default "APEX Application Authentication" method, they will consult the same authentication user list... so USER1 and its password is a valid login for any of the "neighboring" applications...
This may be a concern if you are hosting different clients or users that should not be intermingling with the other applications. You can also define user GROUPS in the same place as you set up each workspace user. Each application can have its own security filter that permits access by membership of BOTH user/password authentication AND membership in the appropriate access group.
Sharing workspaces may also be a problem because of the unique user name restriction of a single workspace. You can get around that by:
Defining different name-spaces for each application:
Email addresses are good: "someuser#sampledomain.com"
An app id prefix such as: SHOP_EDNA, SHOP_GARRETT, TC_KAREN, TC_MARLOWE, MY_BORIS etc.
Different name styles: first name only, first name + last initial, etc.
To keep things simple, you can always just spin up a brand new workspace: a warning however is that common user names like `ADMIN` are NOT the same between separate workspaces. There shouldn't be much concern however because apps or workspace users may have the same or different schema access privileges to the database back end.
A Word of Caution to Administrators and Developers:
When you go live with an application or multiple applications on a user-facing system, keep in mind the deployment destination (i.e., the workspace) and what else is sharing that workspace. There are some real situations where apps are not intended to be shared or accessed by other "inside" users. Be sure to read up and understand the security constraints and methods of using Default Apex Authentication security so that it's more than luck that protects your own production/live deployed applications.
I do have the similar requirement, linking from one application page to another.
Tried the above mentioned solution, but still asking to login to second application. My Apex ver is 5.0.3 and trying in same workspace.
Created new authentication schemes for each app with same cookie name and set them as current authentication. Scheme type are Application express accounts.
Setting the link as below from first app page to second.
href="http://servername:port/apex/f?p=224:2:&APP_SESSION"
Could anyone provide a solution, please?
Just an update on this.
I am currently using v21.2 and this is how I do it:
In both applications, go to Shared Components > Authentication Schemes > (Select your Auth Scheme);
Scroll down to Session Sharing and select 'Workspace Sharing';
In one of the applications (source), create a link (as a Navigation Bar List entry, for example) like f?p=173:1:&SESSION., where 173 is the target application ID and 1 is the target page.
After some research, I've found out that this feature (Session Sharing Type) is available since v18 of APEX.
I'm looking for information on how to implement secure pages using ExtJS 4. By secure pages I mean the user will log into our website using Siteminder (SSO) and so we will have the user's identity. Then we would determine what roles the user would have by making a database/LDAP call and only render those views/components that the user has access to.
Several questions come to mind:
1.) Of course I would expect we would do the authorization check prior to rendering the pages on the server-side, so how do you do this prior to firing Ext.onReady()? I need to have the ExtJS wait for the response from the server?
2.) What is the best way to organize a page's components where the case may be someone could see a particular component and another person cannot?
3.) How do I deliver the resulting page (i.e., the pieces the user has access to) to the client?
TIA!
If you're working from a Java background and are comfortable using Spring, I wrote up an approach using Spring Security here. This will allow you to plug-in any authentication mechanism you want. The main difference is that instead of using an index.html to bootstrap the application, I have a JSP so that the Spring Servlet Filter will fire for authentication. The Ext JS app blocks until the user is authenticated and the user's roles/permissions are provided.
Use a server side technology to pre-process authorization by putting your JS App launch script into a JSP/GSP. What this does is forces server side components to kick off first and then render the HTML/JS/CSS to the client. For full RIA app use index.gsp(or jsp) and the your URL stays "domain/contextroot" .
You can interrogate access privs to content via ajax request to server or alternatively you could set JS variables via again JSP technology that is processed first before the rest of the client response is returned.
< g:javascript>
//global env var definition
var env = "${System.getProperty(Environment.KEY)}";
< /g:javascript>
Both of these are not 100% safe as client side code can be altered. The real security enforcement must be handled on server side when data is submitted for processing.
'3. Easy way would be to hide/show views etc based on 2. above. There are also some experimentation out there with modularizing the client side MVC application by lazy(manually) initializing controllers that may or may not be needed.
Hope this helps.
DB :)
I am currently experimenting with the following solution. Although it will only work for apps with a rather simple set of users, it could be of some help to you.
To begin with, user authentication is done without extjs, using a simple HTML/CSS page. Once the user logs in, its details (user id, role) are saved into the PHP session. And then the page redirects to one of two extjs apps.
One app for normal users (I'll call them clients), these are people who's client side JS does not include any admin functionality. The other app is for admins.
Both apps have their classes inherit from base classes. So we have, for example, base.mainMenu from which both admin.mainMenu and clients.mainMenu inherit. The only difference in the app.js script is the controllers loaded, and per extJS 4 dynamic loading module, only the related views are loaded (ie, seen on the client side). In my case, all pages load dynamically anyway, so my users can only dynamically load pages in their mainmenu.
The admin app blocks certain features using a global JS variable that includes the user's role. So for example, the hiding of an 'edit' button from moderators (an admin group with less rights) is done once the view is loaded (in practice this is actually done by not loading a plugin that allows editing on the view).
To wrap it all up, any call to the server checks whether the session user has rights for the requested operation, so regardless of client side scripts, server operation can only be performed by people with the appropriate rights.
To summarise, you have 3 different strategies that you can mix-and-match:
Loading different apps for different users. If your classes all inherent from base classes, this is easier than maintaining 2 or more completely different apps.
Using a global JS variable to disable/enable certain features for certain users. This is only good if you don't have a problem with the client side loading features that are then disabled (but still seen by debuggers).
Regardless of anything, all server-side calls are checked against session variable.
check out Role-based access control. I use Yii's database-based RBAC, and have a php script that returns the rbac rules in json format when ext starts up
on the client, the best bet is to simply hide or disable functionality that is not allowed.
on the server, you should throw a 403 http error if the user is not allowed to perform a function. handle ajax exceptions in ext and check for 403s.