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!
Related
I work with a large university and we track hundreds of subdomains and we also have a few apps. I'm looking for the best solution as we migrate to GA4. (I know, should have been done long ago.) We currently have 20+ Properties which all contain up to 25 Views, each configured to track individual subdomains or apps and we grant user access to these individual Views.
With GA4, Views are deprecated. I'm wondering if anyone has dealt with this type of challenge and how they split up subdomains. We need to keep one account (if possible) and a general plan of action for breaking up all these domains so we can streamline the Analytics data for our end-users.
We do use Google Tag Manager as well.
So far, we have one "main" GA4 property with a single datastream for the root web. The app side is not configured. We also have about 3 other properties setup for individual big players (i.e. colleges or departments which we know will need lots of customizations).
I'm wondering if we should make more properties with multiple "web" datastreams for the many subdomains, but then, how might this affect user engagement with this new Analytics model. Should we handle this in a completely different way.
You don't make properties for stakeholders. You make properties for tracked activity types. Duplicating the tracking is not a good solution.
You don't have the views, but you have the hostname dimension which you can use to filter reports. Feel free to make hostname-based segments and teach your stakeholders use them.
Finally, native app tracking is done through Firebase. Firebase can then be linked to GA4 as its own stream. Better to keep in the same property you keep the web data.
The general rule is: Don't make additional properties unless you know what you're doing. Additional properties will increase complexity on both ends: the collection and the post-processing of data. Increasing complexity needlessly is just pure incompetence that will make many people frown upon it when they inherit your design.
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.
I have a website that revolves around transactions between two users. Each user needs to agree to the same terms. If I want an API so other websites can implement this into their own website, then I want to make sure that the other websites cannot mess with the process by including more fields in between or things that are irrelevant to my application. Is this possible?
If I was to implement such a thing, I would allow other websites to use tokens/URLs/widgets that would link them to my website. So, for example, website X wants to use my service to agree user A and B on the same terms. Their page will have an embedded form/frame which would be generated from my website and user B will also receive an email with link to my website's page (or a page of website X with a form/frame generated from my server).
Consider how different sites use eBay to enable users to pay. You buy everything on the site but when you are paying, either you are taken to ebay page and come back after payment, or the website has a small form/frame that is directly linked to ebay.
But this is my solution, one way of doing it. Hope this helps.
It depends on how your API is implemented. It takes considerably more work, thought, and engineering to build an API that can literally take any kind of data or to build an API that can take additional, named, key/value pairs as fields.
If you have implemented your API in this manner, then it's quite possible that users of this API could use it to extend functionality or build something slightly different by passing in additional data.
However, if your API is built to where specific values must be passed and these fields are required, then it becomes much more difficult for your API to be used in a manner that differs from what you originally intended.
For example, Google has many different API's for different purposes, and each API has a very specific number of required parameters that a developer must use in order to make a successful HTTP request. While the goal of these API's are to allow developers to extend functionality, they do allow access to only very specific pieces of data.
Lastly, you can use authentication to prevent unauthorized access to your API. The specific implementation details depend largely on the platform you're working with as well as how the API will be used. For instance, if users must login to use services provided by your API, then a form of OAuth may suffice. However, if other servers will consume your API, then the authorization will have to take place in the HTTP headers.
For more information on API best practices, see 7 Rules of Thumb When You Build an API, and a slideshow from a Google Engineer titled How to Design a Good API and Why That Matters.
I've searched all over for a possible fit for providing basic commerce functionality (doc'd below) in a white label site, that is dirt simple to admin, and preferably supports auto creation of the site. Super nice to have would be SaaS.
I'm hoping someone has done this before, has a suggestion, or can at least put me out of my misery.
I don't need anything fancy, just a way to light up a vendor site that:
Mandatory:
White Label. This includes any financial components
can connect to a single shared catalog that is shared between many vendors
pick the products they want for their site
Has Social Networking abilities
Nice to Have
has a blog per site (can be a logical
separation)
Has a CMS per site (Can be a logical separation)
Auto creation
Also, SaaS is highly preferred.
The closest I've come is Drupal Commons on the DIY side, but I'd have to see if Commons will work with the existing modules for commerce. Ning is a good example of what I'm trying to do.
DIY, SaaS, whatever, what I really need is some way to provide the above either through process (e.g. Drupal + Aegir) or though a paid service. Custom coding is a last resort for this project.
Take a look at Wordpress 3 multisite with a combination of some plugins from WPMUDev.org... specifically for a basic setup:
Marketpress (Ecommerce) & Supporter (A Pseudo SAAS plugin)
and for good measure i would add some extras like google analytics, WPMU SEO, Mailchimp Integration, ect.
Ive got a pretty complex version of this currently built that i've setup to be easily customizable and i can fork to new "networks/domains" for niche markets and runs on an NGINX server on the Rackspace cloud. Users get subdomains and Every User can map their own domain. Super fast. Super easy to manage and completely able to whitelabel the backend. I develop these types of systems routinely for clients and have reasonable dev rates if you need any help in this area.
We are working with an existing SharePoint solution for a Company (its an Intranet). Now, the company is splitting into two and so is their intranet. Each company, of these two, from now on will have their own Intranet. So, idea is to split this Intranet (which is just a web application) into two web applications. But wait, these companies will also have some information to share in between. So, the idea is to put the shared information (Administrative stuff etc) into a separate web application. So, we have three web apps so far.
Previously, Company's intranet was managing the data of about 50 facilities in the form of Subsites. Now, according to new design, each web application will have 25 facilities each. In other words, each company will have 25 facilities. But, problem is that each facility is having large amounts of data almost 5GB+. So, its not possible for me to put the restriction quota at the site level. Although, we can put restriction on the size at SiteCollection level (as per my understanding). So, the idea so far is to create one site collection for each facility, it means we will have 25 site collections in a web applications. Navigation could be a nightmare. But, can we solve navigation problem with managed path etc?
any other suggestions/improvements will be warmly welcome and appreciated! Even your little comment may help me to improve my design ;)
In the proposed design, you will have to manually setup the navigation (managed paths will probably not help unless you want to have something other than /sites/ in the url).
I do question why you now have to split each of the facilities into their own site collection when, before the split, subsites worked. I would only recommend each facility be a unique site collection if you can forsee being asked to move facilities between the two new companies.