Directus 7 is a headless cms which also has an App for editing data. I want to create a website where the public will be able to publish data.
So should I define users in the directus_users table and give them access to the Directus Application so they can contribute and edit data they have created, or should I define users in my own tables and write a frontend for them to create and edit data, and leave the Directus Application for administrators?
I'm asking because I am new to Directus 7 and don't yet have a good grasp of the intentions of the Directus 7 Application.
Developer of Directus here.
There is no given way to do things, it depends on what you want to achieve with your application.
If all you're looking for is posting new public data, without having users in your app, you can open up creation of new items in a certain collection for the public role.
If you need users that have specific push access to certain collections, you can do either one of two things:
Use a role in Directus
This allows you to manage their access very granular in the system, but it also means that your user has access to the (specified) data through the Directus app. This might not be an issue for you, but it's a good thing to keep in mind.
Create a new Application Users collection which holds the users of your app, unrelated from Directus.
This means that by default, there's no access to Directus whatsoever, which means you will have to implement your own auth system and add the rows to the database in your own server side.
Related
I want to make a quick, safe and nice application.
For many years I have been programming in PHP and regular ASP. But wanted to go on with .NET and vue.js.
So I have an idea, I wanted to create and plan to do it like this:
I was thinking of using hosting from an external service.
Then I would have three projects:
domain.com/index - Vue.js which will be a SPA, where the user can filter through a catalog, press like and send few api requests (mainly get-requests).
secure.domain.com - Here I will have a .net mvc project where I can use identity. This will make it simple to handle/register users. I will also give the correct session here for authenticated users. And it will affect domain.com/index, where they only are allowed to do some of the things if they are logged in
api.domain.com - This will be the webapi api. Only authenticated users will be allowed to send some of the requests.
I have used several weeks at looking into how to structure this.
But as I do not have much experience with this.
What pitfalls and bad consequences do you see in structuring it like this?
Are there any heads up you want to give me? Or any other recommendations?
I have been trying to melt all of this together in one project, but that has been difficult, because they operate in different ways. So now I have ended up with this, and look forward to
Size of project
It will be a relative small project.
People should be able to register/authenticate themselves (through facebook/google/server login).
Authenticated People should be able to add records(links) to a database. When adding this to the database they may also want to upload files, and choose some additional information.
All people should be able to filter through the catalog of records (5000+) ( Here I am using vue.js/vuex/axios). Here they should be able to comment too on links too.
Webapi will have 8 entities/tables and one view which will GET all the information. 3 tables should be able to have POST.
So it is more or less a catalog, where people should be able to add records and find new ones.
I was planning to use the identity from asp.net core 3.1. It is a "template" where I can easily add 3rd party logins. (https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity?view=aspnetcore-3.1&tabs=visual-studio)
Additional questions:
Can you tell me how request from SPA will be authenticated in your API? (Jwt or cookie)? Why would you like to have a separate identity service, also Why you would like to use asp.net identity (is it because of ease of setup)?
I have not been thinking about authenticating API requests. Was thinking to only have authenticated users who can send POST-requests. And the rest will be get requests. Limited only from the server. Should I have some additional authentication? Does JWT make web APIs safe enough for my use?
Was thinking of using .net identity because it is simple. And I don't want to use time on setting it up.
Since this is your first project of this type, I would recommend to keep it simple.
Just create one web site. Otherwise you might get issues with the cookies not working for subdomains and you will also get issues with CORS. That is, you will get all problems at the same to time (configuration issues, infrastructure issues and the pain from writing the application itself).
You can still have a clean separation by using sub folders (or Areas in MVC) and by using class libraries for the backend (API) business logic.
Once you have mastered the basics (i.e. writing the actual application) you can start looking at other means of separation etc.
Currently I've been tasked to create a bunch of small-to-medium applications, each of them having some common functionality.
Implement a preapproved boostrap-based graphical design. Therefore, they will use the same assets, images, css and JavaScript components.
Share the same licensing-based mechanism. An application service will be built where it will scan a file or database to get the number of licenses available for each app, thus granting or denying access to users. The only thing that varies is the name of the application instance itself.
Use AzureAD authentication.
Each must use the same authorization mechanism. A claims-based mechanism will be built to retrieve the claims from the database, given a user AAD account.
Each must share the same administration console.This console will be the one needed to populate user information and common catalogs.
A service will be built, to show toast notifications within the apps.
An email notification service will be built, to send emails to users when triggered by business rules.
And some other, less important features, but these are the core ones.
A first, perhaps naïve approach, was to create an ASP.NET Core 2 solution for each application, and implement the shared functionality in a sort-of Core assembly that can be shared by each app. However, while this could work for points 2 to 5, I'd still be repeating the graphical UI design for each app (basically, copying the wwwroot folder as well as the shared razor views five times). So, a change tomorrow in a CSS would have to be replicated five times.
Another approach would be to create a single ASP.NET Core 2 solution, implement the shared functionality and the UI, and then use the "areas" feature o ASP.NET Core 2, each area being a different app. The problem to this approach is shipping the app: if I have to install the five apps in a customer's server, no problem. If I have to install, say, only two apps, then I'd have to ship the five apps anyway and find a way to disable the other three apps.
So, I'd like to know if there is a feature in ASP.NET Core 2 for handling this type of scenarios, or alternatively, what are industry-standard architectural designs that could apply here.
In Windows Presentation Foundation with Unity, I can create a common shell, and then load modules in that shell, within the same shell window. So, using configuration files, I can add or remove modules as I see fit. What I'm looking is something similar in concept. I do not want to create five ASP.NET Core solutions and copy-paste the wwwroot folder and implement the same mechanisms of authorization, notification, email, etc., but rather, find a way to load the core, common features and then load additional features.
Thanks in advance.
I recently finished one of my first AgilityJS projects, which is a web-based file browser that lets you create and manage folders and files, and navigate around the folder tree. I followed the various AgilityJS recommendations regarding the design and ended up with all my HTML and Javascript in a single Javascript file.
Now, I would like to provide a "read-only" version of this app which does not have the ability to add/edit/remove files and folders. I'd like to have 2 user types on the website, one type which can only read the files and folders, and another user type who can administer.
My question is, how do I proliferate these permission differences to my AgilityJS app? I know how to secure my endpoints and operations on the server side, but I'm wonder about the best way to do this on the client side. Should I create a separate version of the app with a limited set of functionality? Should I simply hide certain buttons/features? Are there theories, frameworks, etc.? which deal with this issue? Any point in the right direction would be helpful.
LOL - probably one could write books about that topic. Some very basic ideas:
I would start with the philosophical debate according to MVC. There are people argue with the help of MVC that any piece of code and also any piece of data model should never be implemented twice. Business logic and model to the server. The opposite view is focussing on serving users at any cost - even if that means to double maintain code or the model for the sake of avoiding extra round trips. The way in between defines a master source for business code and model and makes sure to follow on other places that leading master (the master will be changed first). Take your choice. Your answer to that question results into boundaries for how the user interface can/have to look like for the user.
You need to think by hard about a permissions concept. Looking at Microsoft I would assume that they invested for all their applications a couple of dozens man years to make up the permission concepts. The ideal permission concept very much depends on your application. So it is close to impossible to work this out without knowing at least a very little of your application. However the permission concept has to come up with policies deciding on roles, groups, access rigths, access levels, context driven permissions (eg. based IP address), permissions black or white listing (permissions each user has at creation). An example from Microsoft: http://office.microsoft.com/en-us/windows-sharepoint-services-help/permission-levels-and-permissions-HA010100149.aspx
Data on the client is not secured!!! Whatever you do on the client, be it data hiding, encryption, compression... - if this is done on the client there are ways to read the data (even by disabling the data manipulation) or by reverting those. Somebody can send data to your server, where the client should not even have given an update form could be implemented by hackers. So as soon as you start to implement permissions make sure, that for all data you send to clients users are permitted to read and that you inlcude permissions checking for each time you add/update data to the database.
What is the best way to manage users with PirhanaCMS?
I would like to prevent some users from adding content (posts etc...) in some categories and prevent that some sites be listed for some users. (For people who don't know it, PirhanaCMS is a micro CMS programmer oriented).
I would like to use the sites features because I'm working on a project in which I'll have a "network" of several sites managed by different entities of an organization. I would like that each entity be only able to see its own site but that the big organization at the top be able to manage every sites. Moreover, within a site I would like that some users be only able to edit some part of the site.
Are these features built-in ? Otherwise what is the best way to implement them myself around the CMS ?
I am using ASP.NET MVC 4 and EF5.
If you take a look at System > Permissions in the manager area you can see that there are permissions you can give to groups for different parts of the manager interface.
There's however currently no built in support for restricting access to different site trees, but you are free to add a feature request for this at GitHub or maybe participate by implementing it and sending a pull request!
The project I'm currently working on is split up in an admin console and the normal frontend.
Both front and backend are in the same Laravel instance.
In the frontend I'm trying to create a user login system that works exclusively for the frontend. It uses a different table and model and it has different relations as oposed to the User model for the admin.
What I can't figure out is a way to use the Laravel Auth class for both systems. Logically Auth uses one single config file, and more to the point, one session name.
One solution that has been brought forward is not to use a different table and model and use some form of acl for the distinction. But I don't like the idea of mixing frontend and backend in this way. Especially because it would mean I'd suddenly have to give the admin User model all the fields and relations previously unique to the frontend user.
It just doesn't seem the right way to do things. I could switch to a different authentication system or seperate the admin into a package with its own configs but the scope of the project doesn't allow for such timeconsuming changes.
I'd welcome any idea's you could provide.
This is a problem that I encountered recently too. The whole separate environment wasn't very easy, especially if you already have development and production environments.
I did however spend some time creating a package to solve this problem, which you can find at https://github.com/ollieread/multiauth. The package itself is essentially a factory class for Auth, that allows you to use multiple instances of it, so you access it like so:
Auth::admin()->check();
Auth::user()->check();
Auth::whatever()->check();
I hope the package helps you or anyone else looking for this approach.
I'm not sure, but maybe it's useful. Why not try to create to separate environment for admin. And then you will have something like app/config/admin/session.php and app/config/session.php for production(which is the default environment).
You can see here how to setup environments http://andrewelkins.com/programming/php/how-to-set-laravel-4-environments/
But as I said it's just an idea, I'm not quite sure of it :)
Sounds like you should consider splitting the app into two codebases if the different user entities rarely or never need to see the same interface. They would still query the same database obviously.
Not only will this solve your auth issues, but also make maintaining the code a heck of a lot easier. For example, while pushing updates to the admin console you would only need to put that app in maintenance mode while keeping the (presumably) more critical frontend up and running.