How do I connect my custom auth script to ejabberd? - ejabberd

I have searched everywhere that I can think of for this. I know how to create my custom auth script (I am using Python) but I just can't figure out how to connect it to the ejabberd server. Does it have to be in a special location? Special name? Do I point to it from ejabberd.yml in some way?
What triggers ejabberd to call my script instead of its own internal auth code?

In ejabberd.yml tell that you want to use external as authentication method, and also provide the full path to your script, see
https://docs.ejabberd.im/admin/configuration/#external-script

Related

Versioned deployment seems to be redirecting to HEAD deployment after OAuth login

I have a google workspace addon which is extending gmail and is using app script oauth to connect our own system, https://github.com/googleworkspace/apps-script-oauth2.
Our system has a development environment and a live environment, each uses a different identity client id secret which need to be used when connecting to each. I have stored these as different project properites with the development properties being prefixed with 'dev-' and i have a function that looks like this:
getScriptPropery function. This function has a variable that should let me change the script properties I access.
I have then created a versioned deployment that uses the live project properties and have kept my HEAD deployment using the develpoment properties. My problem is that once someone tries to login on the versioned deployment they seem to be redirected back to the HEAD version of the code which is using development project properties, this then breaks the login attempt and gives the following error: AppScript login error. I have tested this by adding logging that is only in the HEAD version of the getScriptProperty function and you can see the logs swap to using the development properties after redirecting from the login attempt, Logging example.
Is there a better way to manage deployments/project properties to stop this from happening or have a just missed something with how they are meant to work?

How can I send an .so file to a MySQL instance on Google Cloud?

I am actually using an aggregate User Defined Function (UDF) and I have compiled a shared object file (.so).
In my local instance it is all right. I just pushed the file to my /usr/local/mysql/plugins folder.
The problem is: Now I have to push the UDF file to my remote instance running in google cloud and I have no idea how can I do that. I have searched a lot and didn't find any answer.
Does anyone have a clue about how it can be done?
Google Cloud SQL does not support UDFs.

When does the AWS .NET SDK load credential files? Is it on startup or on initializing client or...?

As my title states, we are using the AWS .NET SDK and on our web.config configured a profile that points to a credentials file(see: https://docs.aws.amazon.com/sdk-for-net/v2/developer-guide/net-dg-config-creds.html using credentials file) on the disk(so out of the source code). This seems to work fine but we are rotating these keys every x period so we need to change the keys within the file. My question is does de AWS .NET SDK notice that the file is changed and automatically load the new credentials or when does it actually load? In other words, if we change the credentials in this file do we need to do additional steps for the application to actually use them?
What I tried now is start up the application locally, change the credentials to a faulty one and calls are still going thru without a problem. Next, I stopped my application and rebuilded in with the same file having faulty credentials. After doing this the application is still able to make correct calls so I'm wondering how this works as if it is falling back on credentials that did work. Or maybe I just didn't test right.
We are using .net framework 4.6.2 application using the aws sdk version 3.3
Also what i forgot to mention is that for each request we initialize the client like this:
using (AmazonCognitoIdentityProviderClient client = new AmazonCognitoIdentityProviderClient(regionEndpoint))
Short answer is creating a client like that will cause the credentials to be read from the credentials file when the first client is created.
The longer answer is when you create without credentials the client uses the FallbackCredentialsFactory class to find credentials either through the credentials file or environment like EC2 instance metadata. The FallbackCredentialsFactory has a static instance of Amazon.Runtime.CredentialManagement.CredentialProfileStoreChain which is what gets the credentials for a profile.
If you want to something different you could have your code create an instance of CredentialProfileStoreChain before creating a client and use that to get the credentials and pass those credentials into the client.

With Keycloak, can you load an LDAP configuration from a file?

When I run Keycloak, I'd like it to load my LDAP configuration (user federation) automatically when it is run, so I don't have to enter it manually. Is there any way to do this with Keycloak? I'm using the containerized version 7.0.0, if it matters. I am also running in standalone mode. Thanks
You should be able to create your realm from a template that has your LDAP configuration in it.
From what I understand from your question, you want to use LDAP as your user Federation server, so you should have an LDAP up and running before starting your Keycloak container, and the container should start with the LDAP configuration.. to do this, I'll suggest a method that is a bit cumbersome at first, but it will give you a better grasp on how to configure Keycloak in the future.
Start by downloading keycloak from the website and run it without putting it in a container.. set up your Realm, clients and everything apart from the LDAP configuration.
Copy the Keycloak.json file outside of the directory, we're going to use that later
Get back to your web interface, configure your LDAP server, and save the configuration.
Now copy the keycloak.json file again, and place both versions in a text comparison tool, Diffmerge for example, and see the difference in the configuration related to your LDAP, that should be added to your container's keycloak.json.
A good practice using keycloak container is to create your whole configuration, and replace the default one, this way your container will start every time with your Realms, clients and all other pre-configured attributes.
OK so I think I figured it out. In Keycloak I had to export the realm via the standalone.sh script as specified in the documentation. Using the kcadm.sh admin CLI did not export the whole realm. Then I could import the realm using the admin CLI later. Thanks for your help it lead me to this answer.

duck (CyberDuck CLI) with google drive

I'm trying to get the Cyberduck CLI (duck.sh) to work interfacing with a google drive (not "Google Cloud Storage") and I'm having problems getting the oAuth authorization to work. I found this thread but it's out of date - as the newer versions of Cyberduck do absolutely work with Google Drive. Using the regular cyberduck GUI I can browse and operate on my G-drive instance, but I can't quite quack the code (sorry!) for how to make this work using the CLI.
[lwobker:~]$ duck -l googledrive://<user>#gmail.com/
Authenticating as <user>…
OAuth2 Authentication. Paste the authentication code from your web browser.
Authentication Code: <pasted pass here>
Save password (y/n): n
Disconnecting www.googleapis.com…
Login failed. Malformed auth code. Please contact your web hosting service provider for assistance.
I've tried a number of different URLs, including:
#gmail.com
me#gmail.com#www.googleapis.com
and a couple of others.
I also can't seem to figure out where the GUI version of cyberduck stores it's authorized credentials... if I could re-use those that would be fine, doing a one-time setup at the beginning doesn't break my use case.
I'm somewhat familiar with the Google Developers API, and I've created one for use with this project, but I can't seem to figure out how the Google "Client ID" and other credentials map to the Cyberduck tool.
Make sure you paste the auth code obtained from the Google login page opened exactly as is without any line breaks. More information is available in the wiki.