My api is protected via jwt, is it possible to specify a jwt token when fetch profile via go tool pprof ?
Currently, I have to config jwt middleware to bypass the /debug/pprof routes.
I couldn't find a way to pass a token via go tool pprof directly, but due to the fact that you can use curl to fetch the profile, there is a simple workaround:
$ curl -o profile.out https://host/debug/pprof -H 'X-Authorization: $TOKEN'
$ go tool pprof profile.out
Related
I am trying to automate setting up of a Keycloak server for an application. Part of that is to set up a Keycloak client using the admin CLI:
kcadm.sh create clients -r MyRealm -s clientId=my-client -s enabled=true
That seems to work; I can see the client is present using the admin console. However, if I try to use that client with the Java client (creating a Keycloak object) even a read-only operation fails due to HTTP 401 Unauthorized. What am I doing wrong?
After much experimenting, I discovered the cause of the problem. If you create a client using the UI, the UI sets the client to be public client with direct access grants enabled by default. The admin CLI however does not, and that results in access through the Java client being denied. You must instead explicitly set those when you create the client using the admin CLI:
kcadm.sh create clients -r MyRealm -s clientId=mc-client -s enabled=true -s directAccessGrantsEnabled=true -s publicClient=true
I have a spring boot application deployed on pivotal cloud foundry.
I'm trying to tunnel (cf ssh) to that application in pcf from my spring boot application, but not able to find any api or client libraries to achieve it.
Actual cli command to tunnel pcf:
cf ssh -N -T -L 10001:localhost:10001 ms name
Any suggestions are welcome.
If you're trying to write Java code that would do the same thing as the cf ssh command, that should be possible. It's standard SSH, but with short-lived credentials so the trick will be generating credentials that you can use from your app.
Here's an example of using a standard SSH/SCP/SFTP client, note that ssh.bosh-lite.com will be your SSH domain, which you can see from cf curl /v2/info:
$ ssh -p 2222 cf:$(cf app app-name --guid)/0#ssh.bosh-lite.com
$ scp -P 2222 -oUser=cf:$(cf app app-name --guid)/0 my-local-file.json ssh.bosh-lite.com:my-remote-file.json
$ sftp -P 2222 cf:$(cf app app-name --guid)/0#ssh.bosh-lite.com
https://github.com/cloudfoundry/diego-ssh#cloud-foundry-via-cloud-controller-and-uaa
That said, you should be able to do something similar with any standard SSH Java library.
As mentioned above, the trick is in getting credentials. The username will be the format cf:application-guid/app-instance-number, which is easy, but the password needs to be generated with cf ssh-code, or the comparable call to the UAA API.
Ex: curl -vv -H 'Accept: application/json' -H "Authorization: $(cf oauth-token)" "https://uaa.run.pivotal.io/oauth/authorize?client_id=ssh-proxy&response_type=code"
This example uses curl to send the request and cf oauth-token to get a valid Oauth2 bearer token for the logged in user. You could get a valid bearer token in a number of ways, including making direct API calls or using the cf-java-client. It just needs to be a valid token for the user that should perform the SSH action (i.e. it would be the user that's running cf ssh).
Hope that helps!
I have completed solr full import, now I have to automate delta-import using linux-cron. This is my shell script:
#!/bin/bash
curl http://localhost:8983/solr/collection/dataimport?command=delta-import
The solr in my server is protected with authentication. so how to authenticate and then do delta-import using curl?
Use the standard HTTP syntax for basic authentication:
curl http://user:pass#localhost:8983/solr/..
I need to fetch a lot of information from LDAP server based on the data stored in a Google Sheet. Does google appscript have any library/module to do so?
If it was possible to execute shell commands in appscript like:
ldapsearch -H ldap://ldap.org.website.com -x -D cn=root -w secret -LLL -b "o=myhost" cn=root
Then it would have been easier. Do you know of any work-around for this?
You have no access to the shell in Apps Script. App Script does has HTTP and JDBC services. You would need to run one of those services as a bridge to your LDAP server.
HTTP to LDAP:
https://serverfault.com/questions/372112/is-there-a-simple-ldap-to-http-gateway-out-there
JDBC/LDAP driver:
http://www.openldap.org/jdbcldap/
The documentation describing how to connect to a kerberos secured endpoint shows the following:
curl -i --negotiate -u : "http://<HOST>:<PORT>/webhdfs/v1/<PATH>?op=..."
The -u flag has to be provided but is ignored by curl.
Does the --negotiate option cause curl to look for a keytab that was created beforehand with the kinit command, or will curl prompt for credentials?
If it looks for a keytab file, what filename will the command be looking for?
Being a once-in-a-while-contributor to curl in that area. Here is what you need to know:
curl(1) itself knows nothing about Kerberos and will not interact neither with your credential cache nor your keytab file. It will delegate all calls to a GSS-API implementation which will do the magic for you. What magic depends on the library, Heimdal and MIT Kerberos.
Based on your question, I assume that you have little knowledge about Kerberos and want simply automate API calls to a REST endpoints secured by SPNEGO.
Here is what you need to do:
Have a Unix-like OS
Install at least MIT Kerberos 1.11
Install at least curl 7.38.0 against MIT Kerberos
Verify this with curl --version mentioning GSS-API and SPNEGO and with ldd linked against your MIT Kerberos version.
Create a client keytab for the service principal with ktutil or mskutil
Try to obtain a TGT with that client keytab by kinit -k -t <path-to-keytab> <principal-from-keytab>
Verify with klist that you have a ticket cache
Environment is now ready to go:
Export KRB5CCNAME=<some-non-default-path>
Export KRB5_CLIENT_KTNAME=<path-to-keytab>
Invoke curl --negotiate -u : <URL>
MIT Kerberos will detect that both environment variables are set, inspect them, automatically obtain a TGT with your keytab, request a service ticket and pass to curl. You are done.
Note: this will not work with Heimdal.
Check curl version
$ curl -V - It should support the feature "GSS-Negotiate"
Login using kinit
$ kinit <user-id>
Use curl
$ curl --negotiate -u : -b ~/cookiejar.txt -c ~/cookiejar.txt http://localhost:14000/webhdfs/v1/?op=liststatus
"--negotiate" option enables SPNEGO
"-u" option is required but ignored (the principle specified during kinit is used)
"-b" & "-c" options are used to store and send http cookies.
I am using version 7.54.0. The following command works fine for me. (please remember/pay attention there are double dashes before the negotiate option).
curl --negotiate -u: '<the_full_url>'