Is it possible to set the Perforce server to by default don't let the users check out a directory, instead of letting everybody update their view-spec to exclude that directory?
Eg: if you would like to check out //code/heavy/stuff you must explicitly add that directory to your view-spec instead of adding a -//code/heavy/stuff yo your spec.
You can install a trigger on the server that generates the default clientspec for a user. With this flexible tool, you can achieve a number of designs. The idea is that when a user creates a new clientspec, the server would fill it in with something other than the default //depot/... mapping for each depot.
One simple idea would be to define the default clientspec to include -//code/heavy/stuff mapping automatically.
Another more advanced idea would be to check to see what groups the user is a member of, and then auto-generate a clientspec appropriate for that user based on his group membership.
If you just want to block people from getting it, then it might be possible with permission mapping.
But then they would never by able to access it, even if they change their client spec.
Maybe you need to (re-)structure your repository so that the heavy part isn't in most users' client specs.
Related
I want to build a command-line application using Go or Node.js. I want to make it multiuser, so a login feature is needed. I can implement the login feature but I don't understand where should I store the user data which can be fetched any moment at runtime.
The user data is needed to check if a user is logged in or not if he is logged in which user it is.
Need help with a method to store user data to check logged in status
Edit:
I had thought of this- If the config file is present that the user is logged in else not. Then I realized that if one tampers the file, the whole point of login feature will get invalid. I am guessing there must be a better way to do it, which I am trying to know by asking here
Many cli utilities opt to store their configuration as a plain text file on the user's home directory.
You can use any of the available configuration formats such as JSON, TOML, etc.
Although it's good to mention that this is not a secure way of storing data and if users should not be able to see others information in any way this is not the preferred way.
I'm using ApacheDS as directory server which is used in applications like Gogs (Git server like GitLab). My idea is to create groups like gogs-users and restrict the login to those group, so that only users who are member of that group are able to login. I have created a groupOfNames for this and a testuser, which is added to the gogs group.
The type of gogs-users is groupOfNames and it has an attribute member which contains the DN of my user (uid=testuser,ou=Users,DC=example,DC=com). So I'm able to see, who is a member of this group.
But I would like to see all groups where a user is a member of. When I open the testuser, I see no attribute that could tell me, that he's a member of gogs-users. I remember that the proprietary Active Directory had an attribute called memberOf whch was queryable in a filter like (&(objectClass=inetOrgPerson)(memberOf=CN=gogs-user,DC=example,DC=com)). That would be exactly what I need.
How can I get this in a free LDAP implementation? I see no way except defining a custom attribute - Which I had to maintenant per hand. That's not good, I would like to have an automated solution, that keep care of those attribute.
Things I already tried
https://stackoverflow.com/a/34502363/3276634 No changes
https://morenews.blogspot.de/2010/12/adding-active-directory-properties-to.html No changes, too
Note: I did a complete reset after each scheme import, to make sure, that my tests are not influenced by previous changes.
Here are Queries that will go either way but ONLY work for Microsoft Active Directory:
Resolves all members (including nested) Security Groups (requires at least Windows 2003 SP2):
(memberOf:1.2.840.113556.1.4.1941:=CN=gogs-user,DC=example,DC=com)
And
All Groups a User is a member of including Nested Groups
(member:1.2.840.113556.1.4.1941:=CN=UserName,CN=Users,DC=YOURDOMAIN,DC=NET))
This is more of an architecture question involving nodejs as implementation.
I have on a folder not exposed by the webserver files that I want to offer to the user.
The way nodejs should expose the resource to the end user is via a one shot link, that once is consumed is no longer available.
The user through the entire experience should never know the real location of the file.
I'm sure this is a common architecture pattern, but I have never implemented something similar.
Looking at scalability, the resource shouldn't be copy either on HD or RAM, and if possible the solution should not relay on a DB token tracking system.
I don't necessary need a code implementation, but a detail explanation on how I should implement it
Thank you so much
Give user a cookie
Create a temporary association (in db) between cookie and a generated ID for the user (or the hash of it, if you want to be fancy)
Give user the ID
When user requests resource by ID:
Test to see if the ID (or its hash, if you want to be fancy) is in the DB
If it is, give the user the resource and destroy the association between the user and the resource ID
There's a db token tracking system. Hey, that's the only way.
One way to avoid depending on a DB, would be to maybe create a symbolic link in the filesystem (based on the token), that would be removed after a request for it. Would not work satisfactory on windows though.
Example (psuedo):
Create token (guid, or similar)
symlink guid -> actual file
once request is completed, remove symlink
However, I don't think there is a reliable way of knowing if the file was successfully downloaded, so you better prepare for that. Some sort of pingback when the file was completely downloaded is probably the most reliable way that I can think of right now.
For scalability, make sure that the symlink is on a shared file system. Clustered node.js instances on the same server, will be fine though.
If this needs to be restricted to an authenticated user, you could combine the guid with your auth token, and prepend/append it before looking for a file.
I've got Mercurial running on IIS7 fine. One thing that is frustrating is that allow_push will only take a list of usernames rather than a group.
To that end, I was wondering if it'd be possible to use a hook to carry out this task. i.e. by passing in the authenticated username, you could check on demand whether the user has the appropriate access. That's all fine if you can pass the username into the hook, for example:
[hooks]
prechangegroup = echo %username%
Unsurprisingly, this always returns the account that IIS is running on. Is there a way to either get allow_push to respect groups - or to pass the logged on user into the prechangegroup hook?
Alternative approaches welcome.
This isn't ideal - and I'd rather do as above. The alternative approach I've taken is to have an external process set the permissions on the folders in IIS for read and execute, allow_pull and allow_push in the hgrc for the repository as appropriate.
In terms of shortcomings:
Its another process that needs to know about the location of the repository.
The process needs a mechanism to find out about updates to the groups (i.e. polling).
I'm using "MyPage" plugin for Trac.
I have figured out it is useful to store SSH keys on my private page as an attachment, so I can clone my GIT repository from any computer.
Then I have our found that any user who can view a History tab, can see the content of the attachment :/
Any idea how to secure this thing?
Since in general this is meant as a feature, you'd like to just block one or several specific attachments from common view.
If this is true, TracFineGrainedPermissions is for you. Then you'll be able to have something like
[wiki:Users/KilldaclickHome#*/attachment/supersecret.file]
killdaclick = ATTACHMENT_VIEW
* = !ATTACHMENT_VIEW
to just deny access to the specific file to anyone but yourself. Have a look at the FineGrainedPageAuthzEditorPlugin for a alternative way to define these permission (from the web-UI instead of direct access to the authz file).
You'll certainly think twice about granting permission 'TRAC_ADMIN' - just a hint that these user can edit the file and possibly circumvent any restriction. But 'TRAC_ADMIN' will have 'ATTACHMENT_VIEW' anyway.