I have an active Trac installation with multiple projects. I am using the AccountManagerPlugin to manage user accounts, and to allow users to manage their own accounts.
My current AccountManagerPlugin configuration looks like this:
[account-manager]
account_changes_notify_addresses =
authentication_url =
force_passwd_change = true
generated_password_length = 8
hash_method = HtDigestHashMethod
htdigest_realm = TracRealm
notify_actions = []
password_file = /home/sms/trac_sites/trac.htdigest
password_store = HtDigestStore
persistent_sessions = true
user_lock_max_time = 0
verify_email = false
This works great, except: Each Trac project currently requires separate authentication. The projects are unable to share their authentication cookies.
Setting auth_cookie_path = /trac does not work, because session data is stored in each project's own database; therefore one project cannot validate the cookie of another. Worse, this causes projects to overwrite each other's cookies.
Using an undocumented two-year-old monkey patch (SharedCookieAuthPlugin) seems like a bad idea.
Is there a solution?
SharedCookieAuthPlugin is indeed the way to go. The author of the plugin (k0s, alias Jeff Hammel) was the person who requested the auth_cookie_path option, specifically for his plugin. The fact that it hasn't been updated in two years just means that it works as it is.
Related
I have a multi-tenancy structure set up where each client has a schema set up for them. The structure mirrors the "parent" schema, so any migration that happens needs to happen for each schema identically.
I am using Flask-Script with Flask-Migrate to handle migrations.
What I tried so far is iterating over my schema names, building a URI for them, scoping a new db.session with the engine generated from the URI, and finally running the upgrade function from flask_migrate.
#manager.command
def upgrade_all_clients():
clients = clients_model.query.all()
for c in clients:
application.extensions["migrate"].migrate.db.session.close_all()
application.extensions["migrate"].migrate.db.session = db.create_scoped_session(
options={
"bind": create_engine(generateURIForSchema(c.subdomain)),
"binds": {},
}
)
upgrade()
return
I am not entirely sure why this doesn't work, but the result is that it only runs the migration for the db that was set up when the application starts.
My theory is that I am not changing the session that was originally set up when the manager script runs.
Is there a better way to migrate each of these schemas without setting multiple binds and using the --multidb parameter? I don't think I can use SQLALCHEMY_BINDS in the config since these schemas need to be able to be dynamically created/destroyed.
For those who are encountering the same issue, the answer to my specific situation was incredibly simple.
#manager.command
def upgrade_all_clients():
clients = clients_model.query.all()
for c in clients:
print("Upgrading client '{}'...".format(c.subdomain))
db.engine.url.database = c.subdomain
_upgrade()
return
The database attribute of the db.engine.url is what targets the schema. I don't know if this is the best way to solve this, but it does work and I can migrate each schema individually.
I am not able to create connection between metabase and LDAP.
I am trying to set it up similar with our Zeppelin configuration:
ldapRealm.contextFactory.url = our_url<br>
ldapRealm.contextFactory.systemUsername = our_username<br>
ldapRealm.contextFactory.systemPassword = our_password
ldapRealm.userDnTemplate = cn={0},ou=people,dc=xha,dc=app<br>
ldapRealm.memberAttributeValueTemplate = cn={0},ou=people,dc=xha,dc=app<br>
ldapRealm.authorizationEnabled = true<br>
ldapRealm.searchBase = dc=xha,dc=app<br>
ldapRealm.userSearchBase = ou=people,dc=xha,dc=app<br>
ldapRealm.groupSearchBase = ou=group,dc=xha,dc=app<br>
ldapRealm.userSearchAttributeName = uid<br>
ldapRealm.userSearchFilter = (&(objectclass=*)(uid={0}))<br>
ldapRealm.memberAttribute = memberUid
When I tried similar configuration:
URL, Username, Password, worked well.
I tried use “ou=people,dc=xha,dc=app” for “USER SEARCH BASE”, but it did not work and I get error in log:
errors {:ldap-user-base "User search base does not exist or is
unreadable"}}
So it seems, that “USER SEARCH BASE” is in reality “GROUP SEARCH BASE”.
The only one value which working in “USER SEARCH BASE” is “OU=group,DC=xha, DC=app”
I tried for “USER FILTER”:<br>
cn={login},ou=people,dc=xha,dc=app<br>
(&(objectClass=)(uid={0}))<br>
(&(objectClass=)(uid={login}))<br>
(&(objectClass=)(memberUid={0}))<br>
(&(objectClass=)(memberUid={login}))<br>
{uid={login}}<br>
(&(objectclass=*)(cn={login}))<br>
I also tried with empty filter.
Nothing works yet and I am stuck on this for like 2 weeks.
In log is just:
{:errors {:password “did not match stored password”}}
I also tried steps in https://discourse.metabase.com/t/ldap-debugging/2741 but I am still not able to make it work.
Our “LDAP” accounts have no email -> https://discourse.metabase.com/t/autenticate-by-ldap-a-user-that-have-no-email/5215
I do not know if this is still “hardcoded” in version: 0.34.2
So, do you have any suggestions, how can I figured it out?
Thank you in advance
Peter
Actually I figured it out. "OU=people,DC=xha, DC=app" was correct, but our LDAP schema was huge and there were errors in LDAP's logs, that "SIZE LIMIT EXCEEDED". So we started using MariaDB for storing Metabase settings and I saved settings with "OU=group,DC=xha, DC=app" and then manually changed to OU=people,DC=xha, DC=appin MariaDB.
I'm trying to add ssh-keys to my Google Cloud project at the project level with terraform:
resource "google_compute_project_metadata_item" "oslogin" {
project = "${google_project_services.myproject.project}"
key = "enable-oslogin"
value = "false"
}
resource "google_compute_project_metadata_item" "block-project-ssh-keys" {
project = "${google_project_services.myproject.project}"
key = "block-project-ssh-keys"
value = "false"
}
resource "google_compute_project_metadata_item" "ssh-keys" {
key = "ssh-keys"
value = "user:ssh-rsa myverylongpublickeythatireplacewithtexthereforobviousreasons user#computer.local"
depends_on = [
"google_project_services.myproject",
]
}
I tried all types of combinations of the 2 metadata flags oslogin and block-project-ssh-keys, which always get set without issues. But the ssh keys never appear in GCPs web GUI let alone the authorized_keys file. I even tried adding the depends_on, to make sure the project is existent before adding the keys, but that didn't help either.
Yet, Terraform says:
google_compute_project_metadata_item.ssh-keys: Creation complete after 8s (ID: ssh-keys)
Adding the exact same key manually on the web GUI works fine. At this point I believe I have tried everything, read all the first page Google results to 'terraform gcp add ssh key' and similar queries ... I'm at my wits end.
The issue was that the ssh key was being added to a different project.
I started with Google's tutorial on GCP/Terraform. This creates a generic project with the gcloud tool first. Then proceeds to create accounts using that generic project. This is necessary because you need a user to run terraform against their API. Then they create a new project facilitating these users with terraform each time you apply. The generic project created with gcloud is not being touched after the initial creation.
If you omit the "project" parameter from the google_compute_project_metadata_item.ssh-keys resource, it used the generic project and added the ssh keys there - at least in my case.
Solution: explicitly add the project parameter to the metadata resource item to make sure it's being added to the right project
We have just changed our domain after protracted name change (the name actually happened two years ago!) and our DokuWiki installation has stopped being able to see any groups and memberships.
The config has been updated to reflect the new server and DCs and login is working correctly, it is only the groups that aren't working.
$conf['auth']['ldap']['server'] = 'ldap://MYDC.mydomain.co.uk:389';
$conf['auth']['ldap']['binddn'] = '%{user}#mydomain.co.uk';
$conf['auth']['ldap']['usertree'] = 'dc=mydomain,dc=co,dc=uk';
$conf['auth']['ldap']['userfilter'] = '(userPrincipalName=%{user}#mydomain.co.uk)';
$conf['auth']['ldap']['mapping']['name'] = 'displayname';
$conf['auth']['ldap']['mapping']['grps'] = 'array(\'memberof\' => \'/CN=(.+?),/i\')';
$conf['auth']['ldap']['grouptree'] = 'dc=mydomain,dc=co,dc=uk';
$conf['auth']['ldap']['groupfilter'] = '(&(cn=*)(Member=%{dn})(objectClass=group))';
$conf['auth']['ldap']['referrals'] = '0';
$conf['auth']['ldap']['version'] = '3';
$conf['auth']['ldap']['debug'] = 1;
Obviously I have edited the doain name there, but for the life of me I can't see what's wrong here, It all worked fine yesterday on the old domain.
I should also state that this is an old version of DokuWiki that for various reasons I can't actually update.
The debug line gives me a "ldap search: success" line, but if I add "?do=check" onto any url within the system I get "You are part of the groups"...... and nothing, it can't see any groups.
It's a massive pain as we have a pretty intricate ACL setup for the site, so it's not like I can just throw it open to all.
If anyone has any suggestions, no matter how obvious, please pass them on.
Solved it by changing the dokuwiki authentication plugin that was used, the 'authad' is more simple to use and just works with what I'm doing.
As a side bonus it also means that I have finally been able to get the install upgraded to the current version.
I'm writing a VBscript that I would like to alter the anyonymous authentication configuration for a specific site on my web server. However, I'm unsure of how this is done in the commit path. Currently, I am able to change the setting on a global scale, but I only want to target one particular site folder. My best guess was to simply include the site path at the end of MACHINE/WEBROOT/APPHOST.
'CHANGE ANONYMOUS AUTHENTICATION GLOBALLY (working code):
Set adminManager = CreateObject("Microsoft.ApplicationHost.WritableAdminManager")
Set anonymousAuthenticationSection = adminManager.GetAdminSection("system.webServer/security/authentication/anonymousAuthentication", "MACHINE/WEBROOT/APPHOST")
anonymousAuthenticationSection.Properties.Item("enabled").Value = True
anonymousAuthenticationSection.Properties.Item("userName").Value = "myUser"
anonymousAuthenticationSection.Properties.Item("password").Value = "myPass"
adminManager.CommitChanges()
'MY BEST GUESS AT TARGETING A SPECIFIC SITE (returns error 80070005):
Set anonymousAuthenticationSection = adminManager.GetAdminSection("system.webServer/security/authentication/anonymousAuthentication", "MACHINE/WEBROOT/APPHOST/Sites/InsideFTL/Corp/redirects/netXposure")
The code that you have above should work, are you running it from an elevated command prompt?
You could also try to make sure that it is committing to ApplicationHost.config to make sure it is not a locking issue by setting CommitPath, and make sure that the identity under you are running the script has write access to it.
'CHANGE ANONYMOUS AUTHENTICATION For Default Web Site:
Set adminManager = CreateObject("Microsoft.ApplicationHost.WritableAdminManager")
adminManager.CommitPath = "MACHINE/WEBROOT/APPHOST"
Set anonymousAuthenticationSection = adminManager.GetAdminSection("system.webServer/security/authentication/anonymousAuthentication", "MACHINE/WEBROOT/APPHOST/Default Web Site")
anonymousAuthenticationSection.Properties.Item("enabled").Value = True
anonymousAuthenticationSection.Properties.Item("userName").Value = "myUser"
anonymousAuthenticationSection.Properties.Item("password").Value = "myPass"
adminManager.CommitChanges()