I am relatively new to the UI5 Framework and I have a new use-case in my company that I want to implement with UI5 and OData Services.
Basically the application has two functionalities with different stakeholder:
Role A is able to create new requirements
Role B is able to check the requirements and update them with new
information
How can I implement this the best way? My previous thoughts on that:
Possibility 1:
I have the OData Service in the Backend that is used by two separated application depending on the role. The access is controlled through the launchpad over the PCFG objects. So a specific user can only use the application that he actually needs. I believe that matches the basic granularity of Fiori apps. On the other hand, it invalidates the DRY principle since I would have redundant code like most of the view.
Possibility 2:
I check in the UI5 Framework or OData Service which user is currently using the app and enable/disable the required controls in the controller class. I haven’t come across on how to do this. Is there a way to check which user is logged on? Or how can I implement in the OData service, that only specific information is delivered to the client?
What is the correct way to implement such a use case? Is there a better option that I am not aware of? I would appreciate any thoughts on that matter, thanks :)
Best regards
Suggested Approach
If two roles do not share any common functionalities, then I would go for two separate UI5 apps, so as to keep them simple. In that case, each app would have it's own OData service. But in the backend, you can always have a common class for 'Requirements' which is called by both the OData service implementations. (So as to maximize code reuse). So most of your business logic should be inside the 'Requirement' class, and the OData implementations serve as dispatchers.
To check which user is logged in
This is a common requirement for most of the business applications and it is possible in Gateway/ABAP as well. Within the ABAP context, there is always a system variable available named SY-UNAME, which will provide you the current logged in user's name. You can use it further to derive the user's role.
Related
I’m currently building an ASP.NET MVC 5 EF6 blogging web application.
I have two databases and contexts :
-a database for the actual data of my application (blog posts, blog categories, tags, etc) .
-a database for authentification and membership purpose (users and roles).
I am able to authorize a given user the right to add/edit/delete blog posts, using the authorize attribute in the BlogPostcontroller :
[Authorize(Roles=”Administrator,Author”)]
and it works pretty well..
MY GOAL : let’s imagine I want to grant an user the right to add/edit/delete a subset of all the blog post or blog categories (let’s say only to the “Cooking” and “travel” blog categories).
I started to think about creating a navigation property between the user and the blog category entities, but apparently foreign keys between two separate databases are not supported by the entity framework.
Do you guys have an idea of a walk-around for this problem?
Your help will be much appreciated.
This is what you need.
http://typecastexception.com/post/2014/02/19/ASPNET-MVC-5-Identity-Implementing-Group-Based-Permissions-Management-Part-I.aspx
Basically, the privileges is what you will need to configure and associate user roles.
If you want to keep your authorization data separate from your business data, i.e. in 2 separate databases where one contains user information and permissions and the other contains your blog data, then what you actually want to achieve is externalized authorization. That's actually a great intent. After all, do you keep authentication information with your application data? Of course you don't.
Different frameworks give you externalized authorization capabilities. For instance, in .NET, you have claims-based authorization.
You can also take a generic approach and use XACML, the eXtensible Access Control Markup Language. XACML uses attributes (it's an attribute-based access control model as opposed to simply role-based) and combines them into policies & rules to define what can happen. For instance, with XACML, you can write the following rule: A user can edit blog posts he/she owns.
In XACML, you have the notion of an authorization engine called the Policy Decision Point (PDP). That PDP links together all the information it needs to make decisions. In your case, it will use the 2 separate databases and create the relationships on them.
Now, if your use case is simple, using XACML might prove too much. In that case, just use claims-based authorization.
I'm still not used to the MVCS design pattern. I read in a book that if I was planning to create an app that gets information from an external source, it's better to use MVCS instead of MVC.
I'm currently working on an ios app that gets information from multiple external sources. For example, I'll be fetching info about the weather from a web service, driving directions/time probably from Google, and data from our database via a web service as well.
My question is, do I need to create more than one store object in this situation? Like create a store object for each of the external sources? Or do I just create one for all of them?
I think it really depends on your design approach as you can have dozens of different design approaches which all respect the MVC principles and that therefore are all correct.
Personally I would suggest to try to decompose the problem as much as you can in smaller problems, in order to get the most from the flexibility that a objected oriented environment gives you.
In this case, for instance, you could think about having an abstract store class in which you implement the common functionalities you need to have and then subclassing it for each different web service you need to use and implementing the other functionalities related to that specific service. It's just an idea! I hope this helps.
I'm new to Grails and web development. I started doing a project on Schedule management website stuff. I came across the Service concept that is provided by Grails. I understood the concept, but still I have confusion on when to use services.
For example, I need to implement a search module, where the manager can search for a user to find his schedules. In this case it will be good to implement it as a controller or as a service?
So,
When and where should I use Service?
To add to Grooveek's answer;
It is also nice to use Services to keep your Controllers nice and clean.
So Views just render data to the screen, Domain objects store state, Controllers route the user around the application, and Services perform the work.
I don't have enough reputation to comment on an answer or vote up so I have to provide an answer that really should be a comment. Anyways...
+1 on #tim_yates answer. Gotta love thin controllers. 2 things that I would add to the description of a controller:
Would be to translate parameters from the browser before hitting a service (e.g. Date, number, etc.)
Would be to translate data returned from services into something consumable for the views.
For me, ideally, services would never deal with translating a String parameter to it's inherent type. Or deal with building a model to be displayed on a view.
What and where I should use Service?
When you want your controller do to something that may be reused by other controllers
In our application we're doing a functional separation of service. We have a CorePersistanceService, which provides method to create, delete, update and manipulate Core Domain Classes (core for us).
I think persistance services are a good way to reuse GORM code throughout Grails code. You can create method in domain classes, but I don't like that, it's way less maintanable I think
We have a PDFService class for our PDF creation, a SolrService which connect to Solr, a Statisticservice that gather all our methods which collects statictics on our datas
Services in Grails are a manner to gather methods around a particular functional theme, in order to give possibility to reuse them in controllers (I forgot to mention our SecurityService, which is a pretty good Cross-Applications Example)
I have a site which has an area that requires authentication. Right now I use the roles attribute on all the controllers in that area, and I run a query to retrieve that users ID, and all their settings.
It seems like a code or design smell to me that I am retrieving the userid and settings each time a controller in that area loads up? I'm not sure if I should be using sessions, or if ASP.Net MVC 2.0 provides some unique way to handle this. Another concern is security.
Overall, I don't really know which way to turn. Design wise I would like the userId and settings retrieved only once when the user logs into the area. Right now I grab the userId each time a controller loads up, and then if required, I query the database for their settings each time as well.
One of the rules about security is that you shouldn't try to do it yourself. There are many pitfalls in doing an authentication system correctly without leaving loopholes or backdoors. Thus, in that regard, you might consider the SqlMembershipProvider that comes with .NET. It can be used with MVC and provides the means to get roles and the current security context, is easy to setup and configure and will be more secure than rolling your own.
If you are not using SQL Server, you have a couple of choices. One solution would be to use something like SQL Server Express or SQL Server Compact Edition to maintain the credentials. Another solution would be to mimic the SqlMembrershipProvider database schema and then write a custom provider that communicates with that schema.
The last choice would be to write a custom MembershipProvider class. While this is still rolling your own, it forces you into the structure of the MembershipProvider so that you can swap it out at a later date for a different one (e.g. ActiveDirectoryMembershipProvider) and provides a common interface for interacting with credentials and logins which for example enables easy use of the built-in Login control.
If you are already using a MembershipProvider and are asking about storing additional user-specific data, then I would suggest the SqlProfileProvider with all the caveats I mentioned above about the SqlMembershipProvider. the ProfileProvider provides a structure for maintain user-specific data with the currently logged on user.
For more information:
Introduction to Membership
Implementing a MembershipProvider
ASP.NET Profile Providers
You could also implement a custom identity. They are very easy to implement, and they let you store whatever user information you want in Identity, which is then stored in the cookies that Identity puts down, so you're not hitting the DB every time to get that info.
Just create a new class that inherits from GenericIdentity, and you'll be on your way.
You of course have to be careful how much info you put there since it's in a cookie, but usually user related information in the case you're talking about here isn't so big.
We use a custom identity to store a few bits of info about the user, and it works out pretty well.
You could store an object in session that holds all the required user information. You will just need to add a property in the Controllers, Views or other base classes where you want to retrieve the user information/profile. This would be the authorisation info as opposed to any authentication info (eg Forms authentication)
You might try "Windows Identity Foundation". I've been using it on one of my projects for a while. It allows for "claims-based authentication", which basically means that you get to designate "claims", strings of information that describe the user when she logs on.
Once logged on, the user's claims can be read from the HttpContext.Current.User field. You can also use "Role" claims that seamlessly integrate with a role-based authentication schema; meaning that you can give the user a "manager" role claim and then use `if (User.IsInRole("manager")).
As an added bonus, WIF makes it very easy to re-use your login screen in other applications.
All in all, it's very flexible, but the documentation is very poor. I've asked and answered a number of questions about "Windows Identity Foundation" on StackOverflow.
We have done this quite a few times in the past. Similar to what Thomas mentions, what we have generally done is implemented a new Membership provider based on the Microsoft SQL Memberhsip provider to do this. We inherit from the base MembershipUser class and add any custom properties we would want to have on the user object. You have to implement a database read for the Membership provider on the GetUser implementation, so you can consolidate your extra properties you need into that database read.
If you are using SQL server, Microsoft has release the 2.0 code for it. You can get more information at Scott Gu's blog.
http://weblogs.asp.net/scottgu/archive/2006/04/13/442772.aspx
If you want to start from scratch, they also have good resources at MSDN.
http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx
and
http://msdn.microsoft.com/en-us/library/6tc47t75.aspx
Once you have implemented your provider, you can then add the Membership user to the Items collection of the current web context to get access to it from your code. The non extended properties from the base base user class are also available on the Request thread like normal.
With the Microsoft release of the 2.0 version of the source code , we found it helped us alleviate some concerns that exist about reinventing. Another thing to consider for your implementations is based on your scenario, you can bypass implementing some of the code. An example of this would be the CreateUser code if you are hitting a back end system that already has the credential information.
It seems like you're relatively happy with your authentication process but you want to explore other options for session/settings.
My suggestion has to do with settings only (roles, preferences, etc.)
In my opinion, having to traverse the whole technology stack from UI to Business Tier to DB tier to DB is sometimes a bit overkill.
For data that isn't likely to change during a session, this adds a lot of overhead... There are potentially several data transformations happening (DB (Relational Format) -> ORM -> Web Service XML Serialization -> Web Tier deserialization).
You might consider a session system that doesn't rely on a heavy RDBMS system or on the ASP.NET Caching / Session model. There are options that are very performant and that scale well.
You could use RavenDB by Ayende Rahien (Built for .NET). Its main goal is to provide low latency, high performance access to schema-less JSON documents.
Using this solution, you would set up ravenDB in the web tier so that access to data is very quick.
The first time you authenticate and retrieve settings, you would store the userID and settings information in this session DB.
Every time you load your controller after that, the settings data is accessible without having to go back to the RDBMS.
This DB could also be used to cache other web related data.
As for security, the settings data makes it to the web tier regardless of the method you use. This solution would be no more or less secure than the other options (more secure than an unencrypted cookie). If you needed to, you could encrypt the session data - but that will increase your overhead again.
Just another one of the million options to consider.
Good Luck,
Let us know what you decide!
Patrick.
I'm currently building a "Lifesteam" style website in Rails. A lifestream usually is an aggregate of public content (usually received via APIs).
I'm currently confused about the database structure.
There will be a Users table (as users will be able to sign up and have their own lifestream). I'm wondering whether I should also have a Services table, or have a table for each of the services (Twitter, Delicious etc.) or both. I'm also wondering how these tables would be linked together.
If there was a resource for each service, would it be possible that these somehow inherit from a single Service resource?
Any insight would be a great help, Thanks.
I would probably steer clear of separate tables for each service since it makes it rather difficult to extend the service in the future.
I would be tempted to have a services table which also links to a service_type table. The service type could be RSS or whatever other feed you might support.
Add Feedzirra (http://github.com/pauldix/feedzirra/tree/master) and you're away.
May be use separate table for each service each having a user_id in it. Then they can be automatically linked by the user_id.
I'd use a generic table to handle services in order to make adding a new service easier. You can then handle specificities with extra fields, but in the end services won't be that different from one another.
A generic table to handle services world be great. You can user inheritance to specialize each service.