In Lotus Notes/Domino, we have the functionality of Readers fields, which I know all about. These say who CAN see a document. I would like to know if there is some way (may be undocumented) where you can have that type of thing that says specifically who CANNOT see a certain document.
We have an application for HR, and some of the documents in there reflect negatively about certain people (complaints, for example) and everyone who has access to the database currently can see every document. I would like to hide this type of document from that specific person. I have not enacted any Readers fields on any documents in question.
It would be really nice to have a way to keep that current setup, but insert a factor of who to HIDE the document from like Readers fields do.
I know there are undocumented features people have learned about over the years, and wondered if anyone knows of such a thing that I can use.
Create a role called [ReadAll].
Create a Group called HR Readers and one called HR Restricted.
Add the people who can't read documents to the HR Restricted group. Add all others to HR Readers.
Add these two groups to the ACL and give the HR Readers group the [ReadAll] role.
Add a readers field that is computed to "[ReadAll]" on the documents you want to prevent the people in the "HR Restricted" group to not see.
No, there is no feature that does what you want. Not on a user-by-user basis. You can play with groups and roles, as suggested by Rob Mason, but those groups and roles have to be pre-determined. We asked for Non-Readers fields (at least) 20 years ago so that we could do what you want, but Iris, Lotus, IBM, and HCL never did it. I presume that either (a) it's hard, or (b) there isn't enough demand. Or both.
To hide content from specific people, you can use hide-when formulas within a form. I.e., the hide-when formula on one or more sensitive fields would be set to
#isMember(#UserName; RestrictedUsers)
where RestrictedUsers is a field that contains the list of people who cannot see the data in the fields.
But this is not real security. A user can see the document in views, and can see the hidden fields by bringing up the document properties dialog, or with a tool like NotesPeek. If you're talking about a Domino web app, and users don't have Notes clients and you have strictly-managed desktops so you are sure that is the case+, then it kind of sort of works. Admins and developers, though, would probably have the clients and would be able to see fields in documents that they're not supposed to.
I believe if I simply compute a Readers field to say something like:
whoToHideFrom:="John Smith/org";
#Name([ABBREVIATE];#Username) != whoToHideFrom
I will try this and mark this as successful or not successful after I test it
Related
First of all, I must confess that I'm very, very new in TYPO3, therefore, my questions might be a bit confusing or not properly understandable. So, please be patient with me.
As already stated in the title, I want to create a login page for multiple users and every user should see a customized content, for example some pdf files or slides.
I was able to create a login page and it's working but I have no clue what's happening afterwards. I'm searching for a solution since days but the TYPO3 documentation is super shitty, especially for beginners like me.
My idea was to work with a MySQL database (I don't even know if this is possible). After the login all data about the customer are read from the database and defined files (some pdf and slides) should be shown.
Is this possible like that? Or how is the usual way to do that?
I'm happy for every hint!
Thanks a lot in advance :-)
cheers,
expikx
I tried to find a solution online but without success
you need a custom extension which will render the files based on the logged in user. By using the extension "extension builder" you can create a first version of your extension very quickly which can be used as base.
If you are german speaking, take a look at the videos of Stefan, e.g. https://www.youtube.com/watch?v=dhRBvTZoPQM& which document how to create an extension as well
If you use the Login of TYPO3 you can also use the access-management from TYPO3 for FrontEnd content:
for each erecord (page, content, news, ...) you can decide which group(!) of users can see it.
Each record in TYPO3 normaly contains a field (in the access tab) to select which groups can see this record.
It's up to you to define the groups each user belongs to.
And each group can access some content. TYPO3 merges it and even can give access to one record to multiple groups.
Regarding files like PDFs: if you do not need absolute access restrictions it would be possible to only list links to the files for the apropriate groups. (other users, even not logged in users could access the files if they know the URL)
e.g.:
You have users in three groups like owner of product A, product B, product C.
Of course there are owners of multiple Products.
For each group you can provide content like manuals, updates or lists of service points.
First you can give access to the pages about each product only to member of the matching group. All the content of that pages are visible only after login and if the user belongs to that group.
But you also can have mixed pages:
Maybe news where all updates are shown. Although each news record has (at least) one group to be shown to.
There could be one page with the news plugin to show all news. After login only those records are shown which belong to the groups of the user, other records are hidden. (not logged in users can see only records not restricted to any group)
If you want a individuality of content by person you need a group for each user.
If you want the user to select by himself what his interests are you need a FE plugin where he can select his memberships of individual groups.
If I display user_id that represents each unique user in the db as an atrribute in an HTML element, is that good practice? Because I need the reference to the user if I want to perform an action on that particular user such as adding him to be my friend.
Example in HTML:
<div data-user-id='12' onclick=addFriend(12)>
Click to add John as your friend
</div>
Where 12 is John's actual user id in the db. From a security perspective, is it secure to do this?
it's never a problem to display the user id, actually, it's more secure than showing the username which could be used for logins, but a better solution is to display an id that could be set or changed by the user himself, look for facebook design for reference.
In this case, you want the user to be able to set his public id, and you use this public id to identify the user externally, then you map it to the actual user id internally in the back end.
anyway, all of this is not relevant for an abstract case, to decide how secure it's you need to consider the other security design elements of your application, the main question is always what can a malicious user do by knowing the actual user id?
As usual....it's complicated.
It all depends on how attractive your site is to hackers (and therefore how much effort they're going to invest), and how secure the rest of your solution is.
The first step in an organized attack is to find out as much as possible about your website. Your current solution leaks information. Knowing that users are identified by an integer may be useful (some database engines are more likely to use integers rather than GUIDs). It may help attackers guess other keys. By guessing sequential user IDs, they can find out how many users you have.
Once the attacker has found out all this information, they will use it to try and penetrate your application. The more information they have, the easier it is to create a plan. An individual piece of information may not be useful, but when you put it together with other snippets, it may reveal something useful.
So, no, there's no obvious major risk in this design by itself. It may be part of a wider attack, though, and it could be the bit of information that exposes some other flaw.
I have two questions related to Udi Dahan's article : Don’t Delete – Just Don’t
Sometimes we do need delete, the user (domain expert) request the delete functionality(the real meaning) for wrong data, Say the HR user has a form to add employees and he inserted wrong employee data, He wants to delete this data, It's not used in business yet and it's totally different from Retire or Fire an employee. How to handle the two cases in implementation?
How to make the UI more representative for this case ? using two buttons One shown only if we can DELETE employee and the other if we want to RETIRE employee ?
If the business wants this functionality and if they speak this words then it means they are part of the Ubiquitous language. In this case you may add the delete command. It is however recommended to make the intention clearer; you can name the command as deleteUserBecauseOfInvalidRegistration or so. In this case the delete command is part of the domain model; this means that you can easily restrict the deletion of the user depending on the other properties; for example, a user cannot be deleted anymore if it has approved by the HR manager or so. Then the UI can easily reflect this behavior by hiding the delete button if the operation is not permitted.
An alternative, when the business specialists have heard the word "delete" used by the IT guys so its not from the real domain, you may expose this functionality only in the Admin UI, as a low level command that deletes the rows from the database. The Admin UI could then be accessed only by some higher level persons, like the HR manager.
Is it possible to restrict part of a smart to only a certain user group and if the user trying to edit the smart form content is not of that group, then the user cannot change that portion of the content?
Example:
Let's say I have an Employee smart form with fields for EmployeeBio, EmployeeHireDate, and EmployeeDept. Would it be possible to allow the general author user group to be able to edit the EmployeeBio field, but restrict the EmployeeDept and EmployeeHireDate fields to only an HRAdmin user group?
If it helps, I am using Ektron 9.00 SP3.
As far as I know, you either can edit a content block or you can't; there isn't a way to subdivide permissions on a per-smartform-field basis.
What you can do, is group the "restricted" fields into their own smartform, and then reference that via a content resource selector field.
So your Employee smart form might look like this:
/root/txtName (not in your example, I know...)
/root/rtfBio
/root/cresHRID
Side note: I'm using hungarian notation on my field names here. txt indicates a plain text field, rtf indicates a rich text (html) field, and cres indicates a content resource selector.
Then you could have a second smart form... let's call it "EmployeeHR", and it would have the following structure:
/root/hireDate
/root/txtDepartment
That would, in theory, work. However, I must say that I really don't like splitting up this particular type of data in this way. First, department feels like it would function better as a taxonomy to which you could add the content block. Second, it feels like this type of data would be better served by housing it outside of ektron and then using a DxH (Digital Experience Hub) connector to bring the data into Ektron. This way the external system could handle permissions at a more granular level, and you would still have access to the data within Ektron for use elsewhere within the site.
UPDATE
As I ponder this question some more, another option comes to mind. You could write an ASPX page or UserControl that checks to make sure you're logged in and a member of a particular group before presenting you with a custom edit screen. The following code will check if the current user is a member of the admin group; you can swap out a different group id to fit your needs:
// Not sure off hand which of these using statements provides access to EkConstants...
using Ektron.Cms;
using Ektron.Cms.Common;
using Ektron.Cms.Content;
var userGroupApi = new Ektron.Cms.Framework.User.UserGroupManager();
var isInGroup = userGroupApi.IsUserInGroup(currentUserId, EkConstants.g_AdminGroup);
This could be implemented as an ASPX page on your site, or it could be implemented as a widget and placed on the user's Smart Desktop tab of the workarea. Either way, you have a lot of options for getting what you want, just nothing "out of the box".
I am working on an outdoor site and letting users enter the types of things they saw when they are outdoors. Obviously any item can be written in a large number of ways.
For example, the animal "coyote" can be written like this:
coyote,
wolf,
coyotes,
wild coyotes,
cayotees
So if I let users enter data, how can I have the system understand that all the above examples are about something classified as a "coyote" ?
Why don't you try to rely on Google Sets for each new entry then create links with already existing matched entries in your system ?
You could even crowdsource the validity checking of the links by adding a "Report non related" function.
There are various (non offical) versions of Google Set API.