Related
I faced the below error when importing t24 applications in design studio. The T24 server (TAFJ R18) which I try to connect to is up (jboss is running), but still I face this issue:
Unable to fetch data from T24. Check your connection details and if T24 is up and running.
Subroutine:
Return Code: FAILURE
Response size: 1
Response 1 ->Response Code: EB-SECURITY.VIOLATION,Response Type: NON_FATAL_ERROR,Response Text: Please check your Login Credential and/or access rights,Response Info: 98748ebf-f73d-4e86-8506-950b2fd0b5d2,
Looks like the Username and Password you have provided in the t24-server/config/server.properties is not correct. Make sure you can login to T24 (Browser or Classic) with the T24 User provided in these settings:
#T24 User name used for introspection and deployment (TAFJ)
username=INPUTT
#T24 Encrypted password used for introspection and deployment (TAFJ)
password={encoded}gXhuXZkbBuL09T8WFlRR+w==
Other important settings in this file:
#T24 host name to connect to (IP address or Domain name)
host=localhost
#T24 Web service (TAFJ) port number to connect
ws.port=8080
#Protocol: ftp, sftp or local (TAFC & TAFJ: used for *.b and *.d file transfer)
protocol=ws
#context for web-service
context=axis2
We can check the connectivity and also if anyone restarting the jboss while importing.
We can check the server status is "active" in DS, or we can restart the server connectivity.
And make sure if you are using any VPN to connect the Database and still it is active.
When I am trying to hit from my api to authenticate user from keycloak, but its giving me error Invalid parameter: redirect_uri on keycloak page. I have created my own realm apart from master. keycloak is running on http. Please help me.
What worked for me was adding wildchar '*'. Although for production builds, I am going to be more specific with the value of this field. But for dev purposes you can do this.
Setting available under, keycloak admin console -> Realm_Name -> Cients -> Client_Name.
EDIT: DO NOT DO THIS IN PRODUCTION. Doing so creates a large security flaw.
If you are a .Net Devloper Please Check below Configurations
keycloakAuthentication options class set
CallbackPath = RedirectUri,//this Property needs to be set other wise it will show invalid redirecturi error
I faced the same error. In my case, the issue was with Valid Redirect URIs was not correct. So these are the steps I followed.
First login to keycloack as an admin user.
Then Select your realm(maybe you will auto-direct to the realm). Then you will see below screen
Select Clients from left panel.
Then select relevant client which you configured for your app.
By default, you will be Setting tab, if not select it.
My app was running on port 3000, so my correct setting is like below.
let say you have an app runs on localhost:3000, so your setting should be like this
If you're getting this error because of a new realm you created
You can directly change the URL in the URL bar to get past this error. In the URL that you are redirected to (you may have to look in Chrome dev tools for this URL), change the realm from master to the one you just created, and if you are not using https, then make sure the redirect_uri is also using http.
If you're getting this error because you're trying to setup Keycloak on a public facing domain (not localhost)
Step 1)
Follow this documentation to setup a MySql database (link's broken. If you find some good alternative documentation that works for you, feel free to update this link and remove this message). You may also need to refer to this documentation.
Step 2)
Run the command update REALM set ssl_required = 'NONE' where id = 'master';
Note:
At this point, you should technically be able to login, but version 4.0 of Keycloak is using https for the redirect uri even though we just turned off https support. Until Keycloak fixes this, we can get around this with a reverse proxy. A reverse proxy is something we will want to use anyhow to easily create SSL/TLS certificates without having to worry about Java keystores.
Note 2: After writing these instructions, Keycloak come out with their own proxy. They then stopped supporting it and recommended using oauth2 proxy instead. It is lacking some features the Keycloak proxy had, and an unoffical version of that proxy is still being maintained here. I haven't tried using either of these proxies, but at this point, you might want to stop following my directions and use one of those instead.
Step 3) Install Apache. We will use Apache as a reverse proxy (I tried NGINX, but NGINX had some limitations that got in the way). See yum installing Apache (CentOs 7), and apt-get install Apache (Ubuntu 16), or find instructions for your specific distro.
Step 4) Run Apache
Use sudo systemctl start httpd (CentOs) or sudo systemctl start apache2 (Ubuntu)
Use sudo systemctl status httpd (CentOs) or sudo systemctl status apache2
(Ubuntu) to check if Apache is running. If you see in green text the words active (running) or if the last entry reads Started The Apache HTTP Server. then you're good.
Step 5) We will establish a SSL connection with the reverse proxy, and then the reverse proxy will communicate to keyCloak over http. Because this http communication is happening on the same machine, you're still secure. We can use Certbot to setup auto-renewing certificates.
If this type of encryption is not good enough, and your security policy requires end-to-end encryption, you will have to figure out how to setup SSL through WildFly, instead of using a reverse proxy.
Note:
I was never actually able to get https to work properly with the admin portal. Perhaps this may have just been a bug in the beta version of Keycloak 4.0 that I'm using. You're suppose to be able to set the SSL level to only require it for external requests, but this did not seem to work, which is why we set https to none in step #2. From here on we will continue to use http over an SSH tunnel to manage the admin settings.
Step 6)
Whenever you try to visit the site via https, you will trigger an HSTS policy which will auto-force http requests to redirect to https. Follow these instructions to clear the HSTS rule from Chrome, and then for the time being, do not visit the https version of the site again.
Step 7)
Configure Apache. Add the virtual host config in the code block below. If you've never done this, then the first thing you'll need to do is figure out where to add this config file.
On RHEL and some other distros
you'll need to find where your httpd.conf or apache2.conf file is located. That config file should be loading virtual host config files from another folder such as conf.d.
If you are using Ubuntu or Debian,
your config files will be located in /etc/apache2/sites-available/ and you'll have an extra step of needing to enable them by running the command sudo a2ensite name-of-your-conf-file.conf. That'll create a symlink in /etc/apache2/sites-enabled/ which is where Apache looks for config files on Ubuntu/Debian (and remember the config file was placed in sites-available, slightly different).
All distros
Once you've found the config files, change out, or add, the following virtual host entries in your config files. Make sure you don't override the already present SSL options that where generated by certbot. When done, your config file should look something like this.
<VirtualHost *:80>
RewriteEngine on
#change https redirect_uri parameters to http
RewriteCond %{request_uri}\?%{query_string} ^(.*)redirect_uri=https(.*)$
RewriteRule . %1redirect_uri=http%2 [NE,R=302]
#uncomment to force https
#does not currently work
#RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI}
#forward the requests on to keycloak
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:8080/
ProxyPassReverse / http://127.0.0.1:8080/
</VirtualHost>
<IfModule mod_ssl.c>
<VirtualHost *:443>
RewriteEngine on
#Disable HSTS
Header set Strict-Transport-Security "max-age=0; includeSubDomains;" env=HTTPS
#change https redirect_uri parameters to http
RewriteCond %{request_uri}\?%{query_string} ^(.*)redirect_uri=https(.*)$
RewriteRule . %1redirect_uri=http%2 [NE,R=302]
#forward the requests on to keycloak
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:8080/
ProxyPassReverse / http://127.0.0.1:8080/
#Leave the items added by certbot alone
#There should be a ServerName option
#And a bunch of options to configure the location of the SSL cert files
#Along with an option to include an additional config file
</VirtualHost>
</IfModule>
Step 8) Restart Apache. Use sudo systemctl restart httpd (CentOs) or sudo systemctl restart apache2 (Ubuntu).
Step 9)
Before you have a chance to try to login to the server, since we told Keycloak to use http, we need to setup another method of connecting securely. This can be done by either installing a VPN service on the keycloak server, or by using SOCKS. I used a SOCKS proxy. In order to do this, you'll first need to setup dynamic port forwarding.
ssh -N -D 9905 user#example.com
Or set it up via Putty.
All traffic sent to port 9905 will now be securely routed through an SSH tunnel to your server. Make sure you whitelist port 9905 on your server's firewall.
Once you have dynamic port forwarding setup, you will need to setup your browser to use a SOCKS proxy on port 9905. Instructions here.
Step 10) You should now be able to login to the Keycloak admin portal. To connect to the website go to http://127.0.0.1, and the SOCKS proxy will take you to the admin console. Make sure you turn off the SOCKS proxy when you're done as it does utilize your server's resources, and will result in a slower internet speed for you if kept on.
Step 11) Don't ask me how long it took me to figure all of this out.
IMPORTANT UPDATE IN KEYCLOAK 18
In the newest keycloak 18, they have deprecated the redirect_uri variable for the openid connect logout -> https://www.keycloak.org/docs/latest/upgrading/index.html#openid-connect-logout
Go to keycloak admin console > SpringBootKeycloak> Cients>login-app page.
Here in valid-redirect uris section add
http://localhost:8080/sso/login
This will help resolve indirect-uri problem
For me, I had a missing trailing slash / in the value for Valid Redirect URIs
[For Keycloak version 18 or Higher]
None of the mentioned solutions should be working if you are using Keycloak 18 or a higher version.
According to the version 18 release note. Keycloak does not support logout with redirect_uri anymore. you need to include post_logout_redirect_uri and id_token_hint as parameters.
Please check the answer of this question for more information.
keycloak: using react user can login but when I try logout I get a message "Invalid parameter: redirect_uri"
Log in the Keycloak admin console website, select the realm and its client, then make sure all URIs of the client are prefixed with the protocol, that is, with http:// for example. An example would be http://localhost:8082/*
Another way to solve the issue, is to view the Keycloak server console output, locate the line stating the request was refused, copy from it the redirect_uri displayed value and paste it in the * Valid Redirect URIs field of the client in the Keycloak admin console website. The requested URI is then one of the acceptables.
If you're seeing this problem after you've made a modification to the Keycloak context path, you'll need to make an additional change to a redirect url setting:
Change <web-context>yourchange/auth</web-context> back to
<web-context>auth</web-context> in standalone.xml
Restart Keycloak and navigate to the login page (/auth/admin)
Log in and select the "Master" realm
Select "Clients" from the side menu
Select the "security-admin-console" client from the list that appears
Change the "Valid Redirect URIs" from /auth/admin/master/console/* to
/yourchange/auth/admin/master/console/*
Save and sign out. You'll again see the "Invalid redirect url" message after signing out.
Now, put in your original change
<web-context>yourchange/auth</web-context> in standalone.xml
Restart Keycloak and navigate to the login page (which is now
/yourchange/auth/admin)
Log in and enjoy
I faced the same issue. I rectified it by going to the particular client under the realm respectively therein redirect URL add * after your complete URL.
I had the same problem with "localhost" in the redirect URL. Change to 127.0.0.1 in the "Valid Redirect URIs" field of clients config (KeyCloak web admin console). It works for me.
It seems that this problem can occur if you put whitespace in your Realm name. I had name set to Debugging Realm and I got this error. When I changed to DebuggingRealm it worked.
You can still have whitespace in the display name. Odd that keycloak doesn't check for this on admin input.
even I faced the same issue. I rectified it by going to the particular client under the realm respectively therein redirect URL add * after your complete URL.
THE PROBLEM WILL BE SOLVED
Example:
redirect URI: http:localhost:3000/myapp/generator/*
Looking at the exact rewrite was key for me. the wellKnownUrl lookup was returning "http://127.0.01:7070/" and I had specified "http://localhost:7070" ;-)
I faced the Invalid parameter: redirect_uri problem problem while following spring boot and keycloak example available at http://www.baeldung.com/spring-boot-keycloak. when adding the client from the keycloak server we have to provide the redirect URI for that client so that keycloak server can perform the redirection.
When I faced the same error multiple times, I followed copying correct URL from keycloak server console and provided in the valid Redirect URIs space and it worked fine!
This error is also thrown when your User does not have the expected Role delegated in User definition(Set role for the Realm in drop down).
Your redirect URI in your code(keycloak.init) should be the same as the redirect URI set on Keycloak server (client -> Valid Uri)
Ran into this problem too. After two days of pulling my hair out I discovered that the URLs in Keycloak are case sensitive. However the browser coverts the URL to lowercase, which means that uppercase URLs in Keycloak will never work.
e.g. my server name is MYSERVER (hostname returns MYSERVER)
Keycloak URLs are https://MYSERVER:8080/*
Browse to https://myserver:8080 -> fails invalid_url
Browse to https://MYSERVER:8080 -> fails invalid_url
Change Keycloak URLs to https://myserver:8080/*
Browse to https://myserver:8080 -> works
Browse to https://MYSERVER:8080 -> works
We also saw this, but only on certain URLs. After seeing this clue, I realized that the Java URI constructor has to be able to decode it,
like so URI uri = URI.create(redirectUri);
We had a { and } in our URLs which normally worked fine, but when going through two layers of URL decode/encode, Java decided the { and } were invalid.
We'll be changing our curly braces to something else to get around the double encode/decode issue.
I know other people provided the same answer, but my reputation was not high enough to upvote them. In the redirect menu, Mine had a redirect of " 0.0.0.0:8080/* ". I added
(actualIP) followed by :8080/* and it worked.
In your client, set the origin of your request. In my case, localhost:3000 (javaScript client)
If you are using the Authorization Code Flow then the response_type query param must be equal to code. See https://www.keycloak.org/docs/3.3/server_admin/topics/sso-protocols/oidc.html
You need to check the keycloak admin console for fronted configuration. It must be wrongly configured for redirect url and web origins.
If you're trying to redirect to the keycloak login page after logout (as I was), that is not allowed by default but also needs to be configured in the "Valid Redirect URIs" setting in the admin console of your client.
Check that the value of the redirect_uri parameter is whitelisted for the client that you are using. You can manage the configuration of the client via the admin console.
The redirect uri should match exactly with one of the whitelisted redirect uri's, or you can use a wildcard at the end of the uri you want to whitelist. See: https://www.keycloak.org/docs/latest/server_admin/#_clients
Note that using wildcards to whitelist redirect uri's is allowed by Keycloak, but is actually a violation of the OpenId Connect specification. See the discussion on this at https://lists.jboss.org/pipermail/keycloak-dev/2018-December/011440.html
My issue was caused by the wrong client_id (OPENID_CLIENT_ID) I had defined in the deployment.yaml. Make sure this field is assigned with the one in Keycloak client id.
The problem seems related to an invalid value in Valid Redirect URIs field. You can try with one of these tips:
set the same value of Client ID (if it's a URL) making it end with /* , or
tryingToLearn 's reponse [https://stackoverflow.com/a/51420355/97799] (but beware of security issues).
I into this due to a malformed redirect url in the keycloak client:
https://http://192.168.1.10/hub/oauth_callback
As soon as I took out https:// the error
I'm using version 20.0.2 and, for me, the solution was to simply add a '+' in the "Valid post logout redirect URIs" field:
As stated in the help balloon, "A value of '+' will use the list of valid redirect uris".
I faced a similar issue because I create a realm with two words and had a space on it. eg Test Realm, this gave me this error. I put an underscore and was good to go eg, Test_Realm.
I just started using Postman. I had this error "Error: socket hang up" when I was executing a collection runner. I've read a few post regarding socket hang up and it mention about sending a request and there's no response from the server side and probably timeout. How do I extend the length of time of the request in Postman Collection Runner?
For me it was because my application was switched to https and my postman requests still had http in them. Changing postman to https fixed it.
Socket hang up, error is port related error. I am sharing my experience. When you use same port for connecting database, which port is already in use for other service, then "Socket Hang up" error comes out.
eg:- port 6455 is dedicated port for some other service or connection. You cannot use same port (6455) for making a database connection on same server.
Sometimes, this error rises when a client waits for a response for a very long time. This can be resolved using the 202 (Accepted) Http code. This basically means that you will tell the server to start the job you want it to do, and then, every some-time-period check if it has finished the job.
If you are the one who wrote the server, this is relatively easy to implement. If not, check the documentation of the server you're using.
Postman was giving "Could not get response" "Error: socket hang up".
I solved this problem by adding the Content-Length http header to my request
Are you using nodemon, or some other file-watcher? In my case, I was generating some local files, uploading them, then sending the URL back to my user. Unfortunately nodemon would see the "changes" to the project, and trigger a restart before a response was sent. I ignored the build directories from my file-watcher and solved this issue.
Here is the Nodemon readme on ignoring files: https://github.com/remy/nodemon#ignoring-files
I have just faced the same problem and I fixed it by close my VPN. So I guess that's a network agent problem. You can check if you have some network proxy is on.
this happaned when client wait for response for long time
try to sync your API requests from postman
then make login post and your are done
I defined Authenticate method to generate a token and mentioned its return type as nullable string as:
public string? Authenticate(string username, string password)
{
if(!users.Any(u => u.Key==username && u.Value == password))
{
return null;
}
var tokenHandler = new JwtSecurityTokenHandler();
var tokenKey = Encoding.ASCII.GetBytes(key);
var tokenDescriptor = new SecurityTokenDescriptor()
{
Subject = new ClaimsIdentity(new Claim[]
{
new Claim(ClaimTypes.Name, username)
}),
Expires = DateTime.UtcNow.AddHours(1),
SigningCredentials = new SigningCredentials(new
SymmetricSecurityKey(tokenKey),
SecurityAlgorithms.HmacSha256Signature)
};
var token = tokenHandler.CreateToken(tokenDescriptor);
return tokenHandler.WriteToken(token);
}
Changing nullable string to simply string fixed "Socket Hang Up" issue for me!
If Postman doesn't get response within a specified time it will throw the error "socket hang up".
I was doing something like below to achieve 60 minutes of delay between each scenario in a collection:
get https://postman-echo.com/delay/10
pre request script :-
setTimeout(function(){}, [50000]);
I reduced time duration to 30 seconds:
setTimeout(function(){}, [20000]);
After that I stopped getting this error.
I solved this problem with disconnection my vpn. you should check if there is vpn connected.
What helped for me was replacing 'localhost' in the url to http://127.0.0.1 or whatever other address your local machine has assigned localhost to.
Socket hang up error could be due to the wrong URL of the API you are trying to access in the postman. please check the URL once carefully.
It's possible there are 2 things, happening at the same time.
The url contains a port which is not commonly used AND
you are using a VPN or proxy that does not support that port.
I had this problem. My server port was 45860 and I was using pSiphon anti-filter VPN. In that condition my Postman reported "connection hang-up" only when server's reply was an error with status codes bigger than 0. (It was fine when some text was returning from server with no error code.)
When I changed my web service port to 8080 on my server, WOW, it worked! even though pSiphon VPN was connected.
Following on Abhay's answer: double check the scheme. A server that is secured may disconnect if you call an https endpoint with http.
This happened to me while debugging an ASP.NET Core API running on localhost using the local cert. Took me a while to figure out since it was inside a Postman environment and also it was a Monday.
In my case, adding in the header the "Content-length" parameter did the job.
My environment is
Mac:
[Terminal command: sw_vers]
ProductName: macOS
ProductVersion: 12.0.1. (Monterey)
BuildVersion: 21A559
mysql:
[Terminal command: mysql --version]
Ver 8.0.27 for macos11.6 on x86_64 (Homebrew)
Apache:
[Terminal command: httpd -v]
Server version: Apache/2.4.48 (Unix)
Server built: Oct 1 2021 20:08:18.
*Laravel
[Terminal command: php artisan --version]
Laravel Framework 8.76.2
Postman
Version 9.1.5 (9.1.5)
socket hang up error can also occur due to backend API handling logic.
For example - I was trying to create an Nginx config file and restart the service by using the incoming API request body. This resulted in temporary disconnection of the Nginx service while handling the API request and resulted in socket hang up.
If you have tried all the steps mentioned in other comments, and still face the issue. I suggest you check the API handler code thoroughly.
I handled the above-mentioned example by calling the Nginx reset method with delay and a separate API to check the status of the prev reset request.
For me it was giving Socket Hung Up error only while running Collection Runner not with single request.
Adding a small delay (100-300ms) in the collection Runner solved issue for me.
In my case, I had to provide --ssl-client-key and --ssl-client-cert files to overcome these errors.
Great error, it is so general that for everyone something different helps.
In my case I was not able to fix it and what is really funny is fact that I am expecting to get multipart file on one endpoint. When I prepare request in postman I get "Error: socket hang up". If I change for other endpoint(even not existing) is exactly that same error. But when I call any endpoint without body that request works and after that all subsequent attempts works perfectly.
In my case this is purely postman issue. Any request using curl is never giving that error.
For me the issue was related to the mismatch of the http versions on the client and server.
Client was assuming http v2 while server (spring boot/ tomcat) in the case was http v1
When on the server I configured server to v2, the issue got resolved in a go.
In spring boot you can configure the http v2 as below:-
server.http2.enabled=true
Note - Also the scenario was related to using client auth mechanism (i.e. MTLS)
Without client auth/ MTLS it worked without issues but for client auth the version setting in spring boot was the important rescue point
"socket hang up" is proxy related issue. when we run same collection with the help of newman on jenkins then all test are passed.
change the proxy setting
https://docs.cloudfoundry.org/cf-cli/http-proxy.html
I had the same issue: "Error: socket hang up" when sending a request to store a file and backend logs mentioned a timeout as you described. In my case I was using mongoDB and the real problem was my collection’s array capacity was full. When I cleared the documents in that collection the error was dismissed. Hope this will help someone who faces a similar scenario.
"Socket Hung Up" can be on-premise issue some time's, because, of bottle neck in %temp% folder, try to free up the "temp" folder and give a try
I fixed this issue by disabling Postman token header. Screenshot:
I face the same issue in when calling a SOAP API with POSTMAN
by adding the following data in the header my issue was fixed
Key:Content-Length
Value:<calculated when request is sent>
In my case, I was incorrectly using a port reserved for https version of my api.
For example, I was supposed to use https://localhost:6211, but I was using http://localhost:6211.
It is port related error. I was trying to hit the API with an invalid port.
if it helps to anybody... In my case, i just forgot to use json parser (const jsonParser = express.json();) to have access to json type of objects sending to the server from the client. Be careful, don't waste your time =)
This happened to me while I was learning ASP.NET Web API.
In my case it was because the SSL certificate verification.
I was using VS Code so I oversee about SSL certificate verification and it came with https protocol.
I solved this with testing my endpoints with http protocol.
Another approach can be just disabling the SSL certificate Verification on Postman Settings.
This error was coming for me since the request url is not correct --> here you can see my url does not contains : after http
The url I was using was : http//locahost:9090/someApi
Solution
adding a colon new url is http://localhost:9090/someApi
the socket error was not coming
This is just my case may be your case is totally different as mentioned in the other answers :)
Within ElasticSearch, I configured jdbc river plugin, it works before, after configured shield and assigned with admin user, the ElasticSearch is secured and able to access by TransportClient, but when I run river plugin script, I got the following exception:
pool-3-thread-1] ERROR river.jdbc.RiverPipeline - action [org.xbib.elasticsearch.action.river.jdbc.state.get] is unauthorized for user [ddtuser]
org.elasticsearch.shield.authz.AuthorizationException: action [org.xbib.elasticsearch.action.river.jdbc.state.get] is unauthorized for user [ddtuser]
at org.elasticsearch.shield.authz.InternalAuthorizationService.denial(InternalAuthorizationService.java:247)
BTW, I already modified the JDBCFeeder.java, to pass the shield.user into setting, but no luck!
Settings clientSettings = ImmutableSettings.settingsBuilder()
.put("cluster.name", settings.get("elasticsearch.cluster", "elasticsearch"))
.put("shield.user", "ddtuser:*mypassword*")
How to I change the monitoring-agent.config to go out via proxy with authentication?
The change log states...
Monitoring Agent 2.3.1.89-1
Released 2014-07-08
Added support for HTTP proxy configuration in the agent configuration file.
But I can't see how to do this.
Following wdberkeley's link I can add this value to the monitoring-agent.config file.
httpProxy=http://"pxproxy01":3128
But this gives..
Failure getting conf. Op: Get Err: Proxy Authentication Required
Is there anyway to set the authentication user/password ?
Edit file:
C:\MMSData\Monitoring\monitoring-agent.config
Add line...
httpProxy=http://<insert_server_address>:<insert_port>
e.g.
httpProxy=http://PROXY01.server.com:3128
Then get the proxy control team, who ever they be, to exclude the following from requiring authentication.
https://mms.mongodb.com 80
https://mms.mongodb.com 443
This has worked for me. I now have the MMS Agent on Windows sending stat's to the MMS service.
Thanks to #wdberkeley for starting me off on this route.
wdberkeley, the page you linked to does not exist & the classic page PDF & HTTP versions state 'HTTP_PROXY' not 'httpproxy' (on OSx section & tar.gz section), section '6.6 Monitoring Agent Configuration' does state the correct property name 'httpproxy'.