I have set up trac on my domain for issue tracking. How to I configure it so that when anonymous users visit the domain, ALL they see is a login form. Basically I want 2 security levels:
anonymous - visitors only have access to a login option
users (i.e. everybody else who has logged in) - have access to everything
Thanks!
You can remove all permissions for the anonymous user:
trac-admin /path/to/projenv permission remove anonymous '*'
For details see the Trac permission docs
Trac offers two different permission groups by default:
authenticated
anonymous
The docs describe how to change the group defaults and how you can form new permission sets in the permission groups section.
The solution given by Thomas Zoechling does not work anymore, with trac 1.0.2 one needs to copy the permissions of anonymous user to authenticated manually:
trac-admin /path/to/projenv permission list anonymous
#gets: BROWSER_VIEW CHANGESET_VIEW FILE_VIEW LOG_VIEW MILESTONE_VIEW REPORT_SQL_VIEW REPORT_VIEW ROADMAP_VIEW SEARCH_VIEW TICKET_VIEW TIMELINE_VIEW WIKI_VIEW
trac-admin /path/to/projenv permission remove anonymous '*'
trac-admin /path/to/projenv permission add authenticated BROWSER_VIEW CHANGESET_VIEW FILE_VIEW LOG_VIEW MILESTONE_VIEW REPORT_SQL_VIEW REPORT_VIEW ROADMAP_VIEW SEARCH_VIEW TICKET_VIEW TIMELINE_VIEW WIKI_VIEW
You'll want to look at the AccountManagerPlugin. It allows form-based authentication. You also want to remove permissions form anonymous as described in the other post.
Related
In Redmine is possible to register new account using web interface via
http://redmine/account/register
When Submit is performed browser sends a POST to account\register with this data:
utf8=%E2%9C%93&authenticity_token=6XEpkFIoAsXyIvAk3j%xxxxxxxroM3yJm5yV4dLoExNg%3D&user%5Blogin%5D=myuser&user%5Bpassword%5D=password&user%5Bpassword_confirmation%5D=password&user%5Bfirstname%5D=firstname&user%5Blastname%5D=lastname&user%5Bmail%5D=test123%40mydomain.tld&user%5Blanguage%5D=it&commit=Invia
In logfile is possible to see:
Started POST "/account/register" for 173.102.44.73 at 2017-03-09 15:53:13 +0100
[...]
{
"utf8"=>"✓",
"authenticity_token"=>"long_alphanumeric_string",
"user"=>{
"login"=>"mynewuser",
"password"=>"[FILTERED]",
"password_confirmation"=>"[FILTERED]",
"firstname"=>"myfirstname",
"lastname"=>"mylastname",
"mail"=>"test123#mydomain.tld",
"language"=>"it"
},
"commit"=>"Invia"
}
Redmine has Rest API support but I can't find how to register a new user using JSON.
EDIT: Is it possible to create/register new user via JSON POST using http://redmine/users.json as described here but Administrators rights are needed.
Web interface permits account registration for anonymous users, is it also possible via Rest API ?
The following should work:
create a redmine api-user i.e. api-user-cancreateusers
enable REST API in Administration -> Settings -> Authentication
generate/get the api-user api-key
give the api-user rights to create users
put the api-user name and key into your program/service
profit!
redmine-auth-doc
Edit:
give the api-user rights to create users
as hinted in the comment - it seems there is no such thing. the only way seems to give the api user admin rights (shudder)
alternatively fetch the account/register page and replay with the provided auth_token
Several years ago, I used mediawiki to create a wiki. I had(still have) no idea really how to administrate it. I wanted it to be maintained/updated by only myself. It was to hold a specific set of information for my users.
After a few weeks it became flooded with User submitted pages (in this case not a good thing) and I guess what you'd call "spammers"(?).
How can I set it up so that only a legitimate admin (me) can add/update page?
I thought I had enabled something to do that...but it apparently didn't work.
In MediaWiki, permissions (read, edit, createpage, etc.) can be granted or refused by configuring the $wgGroupPermissions array in your LocalSettings.php file.
There is a set default groups that you can use with $wgGroupPermissions to restrict page creation/editing:
* - all users (including anonymous)
user - registered accounts
autoconfirmed - registered accounts at least as old as $wgAutoConfirmAge and having at least as many edits as $wgAutoConfirmCount
bot - accounts with the bot right (intended for automated scripts)
sysop - users who by default can delete and restore pages, block and unblock users, et cetera
bureaucrat - users who by default can change other users' rights
The group that would apply to only you (as the creator of the wiki) is the sysop group.
For example, to refuse createpage/edit rights for all users except those with the sysop group, you would place this in your LocalSettings.php:
# Deny createpage and edit rights to all users
$wgGroupPermissions['*']['createpage'] = false;
$wgGroupPermissions['*']['edit'] = false;
# Allow only users with the sysop group createpage and edit rights
$wgGroupPermissions['sysop']['createpage'] = true;
$wgGroupPermissions['sysop']['edit'] = true;
The "*" character indicates that this rule will apply to all groups. Then, we add an exception to that rule for the "sysop" group, allowing users with that group to create or edit pages.
I'm using pas.plugins.sqlalchemy on a fresh new Plone 4.1 installation.
I set Plone to have the email address as login name.
It's all ok, but If I want to change the email address via personal-information panel I obtain an error:
You are not a Plone member. You are probably registered on the root user folder. Please notify an administrator if this is unexpected.
In case I would change another personal data field I don't obtain errors.
The problem seems to be the set_own_login_name function of Products.CMFPlone (utils.py).
Details here http://pastie.org/3780218
Thank's
Vito
Are you logged in as an admin user defined in the Zope root?
If that is the case, then see if you can change the login name by going to the acl_users in the Zope root and changing it there.
Otherwise, temporarily switch off emaillogin, change your email, and switch emaillogin back on.
Note that there is a comment (by me) in the utils.py code right before this KeyError is raised, which points to a possible solution that I don't really like:
# PLIP9214: For a user in the zope root we could do something like this:
# userfolder = member.getUser().__parent__.users
# userfolder.updateUser(member.id, loginname)
# But it is probably best not to touch root zope users.
I'm checking if this is a sitecore bug, or if I'm missing something obvious.
EDIT FOR CLARIFICATION: The problem I'm having is that I'm trying to set up the configuration settings in the Domains.config file so that Sitecore shouldn't be creating (and/or returning) an anonymous user for a domain set up this way. However, if I use the Domain.GetUsers() function on the domain, I still get the anonymous user returned.
The membership provider is a custom built and connects to LDAP in read only mode.
Details
Using Sitecore 6.4.1 and given the following domain configuration in App_Config/Security/domains.config
<domain name="DOMAINNAME" ensureAnonymousUser="false" anonymousUserName="" everyoneRoleName="" />
and these comments in that domain.config file
anonymousUserName: <snip> Set to blank to disable the anonymous user for the domain. Optional
ensureAnonymousUser: Indicates if the domain should ensure that an anonymous user for the domain exists in the Membership database. Optional - default value: false
everyoneRoleName: <snip> Set to blank to disable the everyone role for the domain. Optional - default value: Everyone
If I use the following code,
List<Sitecore.Security.Accounts.User> users = new List<Sitecore.Security.Accounts.User>();
var domain = Sitecore.Security.Domains.Domain.GetDomain(DOMAINNAME);
users.AddRange(domain.GetUsers().ToArray<Sitecore.Security.Accounts.User>());
I get the anonymous user included in users list. I assumed from the comments in the domain.config file that I shouldn't get the anonymous user if I set up my domain as above.
Is there something obvious that I'm missing?
Just a guess as I have not used 6.4 yet or tweaked any of those types of setting before... but I believe Sitecore always comes pre-packaged with the Anonymous user in the membership. By setting ensureAnonymousUser to false you're just telling it not to ensure its there, but its already there by default. Why don't you try this test:
Set ensureAnonymousUser to true then delete [*] the Anonymous user from the user manager.
Log out and back in and see if it's there again. If so then the "ensure" aspect of that worked. So...
Set ensureAnonymousUser to false then do the same thing. Does the user come back?
This is really just a hunch on how it works -- I don't have an environment like that setup right now to play with, but its worth a shot.
[*] - to delete a user form the User Manager, go to Sitecore > Security > User Manager
I think it's more question to membership provider you use. Take a look at Active Directory Module
Maybe this is something that could help you.
How can I change an Active Directory user password using Directory Services without knowing old password?
You are probably searching the SetPassword method, which you should invoke on a DirectoryEntry object.
Check the "Reset a User's Password" example here: Howto: (Almost) Everything In Active Directory via C#.
EDIT:
If you are having problems with the directory entry being null, you are probably passing a wrong path. The path should be something like this:
DirectoryEntry entry = new DirectoryEntry("LDAP://CN=johndoe,CN=Users,DC=acme,DC=com");
There is a new library introduced in .net 3.5 called System.DirectoryServices.AccountManagement. It simplifies user management stuff.
public void ChangePassword(string dn, string newPassword)
{
using (var context = new PrincipalContext(ContextType.Domain))
{
using (var user = UserPrincipal.FindByIdentity(context, IdentityType.DistinguishedName, dn))
{
user.SetPassword(newPassword);
}
}
}
As an MCSE, I do password resets many times a day so I can tell you something about this.
There are basically two operations you can perform with an Active Directory password - a change, and a reset. Changing a password requires that you know the current password on an account, but resetting a password does not require you to know the current password on an account, so in a way, in order to change a user's password without knowing the password, you really need to perform a password reset operation on the account.
By the way, i believe there are two seperate Active Directory extended rights that control each of these permissions, but I am not intimately familiar with them, as I am a delegated admin who is delegated thos abillity.
So, please keep in mind that any attempts to reset a user's password will fail if you don't have the reset password right granted to you on the target user account.