Background
We used to access Jenkins via Hostname and port format and never had issues. eg : http://Jenkinsci.company.com:8080.
We had an internal requirement to enable Jenkins access via company Netscaler (https://apps.company.com/).
So new Netscaler context was created and new url :https://apps.company.com/jenkins now points to -> http://Jenkinsci.company.com:8080. I also added JENKINS_ARGS="--prefix=/jenkins" in etc/sysconfig/jenkins.
Issue
Initially we couldnt login. As soon as we clicked on login, we used to get redirected to http page. i.e
https://apps.company.com/jenkins -> http://apps.company.com/jenkins.
. So since login was not working, http to https redirection was setup at Netscaler level. Then login worked.
Now we observed we couldn't add credentials in Jenkins.
Now after adding the credentials, the drop down doesn't show the newly added credentials.
I debugged in Browser and could see the below error message.
Mixed Content: The page at 'https://prod.company.com/jenkins/job/test1/job/test/configure' was loaded over HTTPS, but requested an insecure form action 'http://prod.company.com/jenkins/descriptor/com.cloudbees.plugins.credentials.CredentialsSelectHelper/resolver/com.cloudbees.plugins.credentials.CredentialsSelectHelper$ItemContextResolver/provider/com.cloudbees.hudson.plugins.folder.properties.FolderCredentialsProvider/context/test1/addCredentials'. This request has been blocked; the content must be served over HTTPS.
I also compared the network messages of adding credentials via Netscaler and directly via host and they look same except in success scenario there are couple of more steps executed.
Success
Request URL: http://Jenkinsci.company.com:8080/jenkins/descriptorByName/com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl/checkId?value=&$provider=com.cloudbees.plugins.credentials.CredentialsSelectHelper%24ItemContextResolver&$token=test
Request URL: http://Jenkinsci.company.com:8080/jenkins/descriptorByName/com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl/checkId?value=asdad&$provider=com.cloudbees.plugins.credentials.CredentialsSelectHelper%24ItemContextResolver&$token=test
Request URL: http://Jenkinsci.company.com:8080/jenkins/descriptor/com.cloudbees.plugins.credentials.CredentialsSelectHelper/resolver/com.cloudbees.plugins.credentials.CredentialsSelectHelper$ItemContextResolver/provider/com.cloudbees.hudson.plugins.folder.properties.FolderCredentialsProvider/context/test/addCredentials
Request Method: POST
Request URL: http://Jenkinsci.company.com:8080/jenkins/job/test/job/tess/descriptorByName/hudson.plugins.git.UserRemoteConfig/fillCredentialsIdItems
Failure
Request URL: https://prod.company.com/jenkins/descriptorByName/com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl/checkId?value=&$provider=com.cloudbees.plugins.credentials.CredentialsSelectHelper%24ItemContextResolver&$token=test1
Request URL: https://prod.company.com/jenkins/descriptorByName/com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl/checkId?value=sdfsr&$provider=com.cloudbees.plugins.credentials.CredentialsSelectHelper%24ItemContextResolver&$token=test1
Any idea what may be the issue and way to resolve without putting a SSL certificate to jenkins instance?
Thanks in advance.
I spoke with Netscaler team and initially we added http to https redirection, but it didn't work.
Then I shared below link with them.
Jenkins Reverse Proxy setup
In our setup, Netscaler was accessed via https ,but Jenkins was accessed via HTTP. So we needed to set "X-Forwarded-Proto" header in Netscaler for the request rewrites.
Initially we set X-Forwarded-Proto" header in Netscaler for the response rewrites and it was not working. Be aware that there are very minimal logs and debugging will be difficult.
Hopefully this helps someone.
Related
Requesting for some help here. Kind of stuck with a use case. We are trying to integrate OneLogin with our app via Spring security.
The entry point to our application is Azure App Gateway that routes the requests to load balancer further routing to the VMs where the service is deployed. Everything works fine if we DONOT override the hostname in Backend settings for any incoming request, leading to the App Gateway host only getting passed for every request. Here the App Gateway URL being set as the redirect URI in Spring security auth endpoint call.
The problem appears when the Apigee is used as the entry point to our application. Apigee routes the request to App Gateway routing it further to load balancer and VMs. Here, we DO have to override the host as Apigee host name in order to authenticate the client to the OneLogin server. The Apigee endpoint is set as the redirect URI in the Spring security auth endpoint call.
However, the server responds back with "possible CSRF detected - state parameter was required but no state could be found" error. Tried different possible solutions from other SO links to resolve this error like providing a session cookie name, but did not help. Our OneLogin server and client application are also in different domains.
The only thing that works here is when we DONOT override the hostname in Azure App Gateway Backend settings and pass the App Gateway URL as the redirect URI in auth endpoint call. But the problem is it shows the App Gateway URL in the user browser, which we do not want because in an ideal scenario, the user should see only the Apigee host in the browser url and not the App Gateway host. So, is there any way to re-route/redirect/override the URL to Apigee URL in Azure App Gateway settings without the call being made to Apigee endpoint. Just the user sees the Apigee url in the browser, but internally all calls are made to App Gateway endpoint only.
Or the other solution could be to prevent the CSRF issue when Apigee hostname is used as the redirect URL in the auth endpoint instead of App Gateway host. But not sure how to resolve that.
• In your scenario, when you are not overriding the hostname in the Azure application gateway backend settings and pass the ‘Application Gateway’ URL as redirect URL in the ‘Authorization endpoint call’, the application gateway URL is shown in the user’s browser which is not desired since the Apigee host redirects the authentication requests to the ‘App gateway’ endpoint.
Therefore, without the call to be made to the ‘Apigee’ endpoint, you can surely redirect it to the Apigee redirect URL in the Azure application gateway settings by configuring the ‘Rewrite URI rules’ in the gateway. These rewrite rules will check for any presence of configured URLs or specific paths and will therefore, change the original URI path to the new path configured. As a result, please follow the below given snapshots as steps for configuring the same as stated above: -
Thus, as shown above, you can configure the ‘Rewrite rules’ in a ‘Standard V2’ SKU application gateway for redirecting response requests of ‘authorization endpoint call’ from application gateway URL to the Apigee endpoint hostname configured. In this way, when the application gateway URL is shown in the browser, it will be rewrited to the apigee endpoint hostname’s URL in the browser and accordingly the user at the receiving end will be able to see the Apigee endpoint hostname as a result fulfilling your requirement.
For more details regarding the above, kindly refer the below link: -
https://learn.microsoft.com/en-us/azure/application-gateway/rewrite-http-headers-url#modify-a-redirection-url
I was trying out the curity configuration for an authentication service and a token service for OAuth and OpenID Connect locally. After all the configuration, when I was trying to test it with OAuth Assistant, I get an error:
Bad request
The request could not be processed
In the terminal, I can see these two INFO logs for particular
se.curity.identityserver.util.AllowedFrameOriginUtils - Requested origin is not allowed: 'http://localhost:...'
se.curity.identityserver.controllers.authorize.AuthorizeOAuthRequestModelProvider - Could not establish the redirect uri for request and client www. If this error occurs *after* being redirected to the authentication service and back, then this error has probably occurred because the original session cookie has been lost. Ensure that the cookie named 'sessionid' was sent to the authentication service. If not, check that the user's browser is not withholding it (for example by the cookie jar becoming full) and that a reverse proxy is not interfering with it.
There is no issue with sessionid. Anyone know how to fix this issue?
I'm using https in redirect_uri field of OAuth2. But when I connect to google client, I'm redirect to http url, not https. Here is a part of the code:
$client->setClientId($client_id);
$client->setClientSecret($secret);
$client->setRedirectUri("https://mydomain/myphp.php");
$client->setScopes(array('https://www.googleapis.com/auth/calendar'));
I use the example from http://www.daimto.com/google-oauth2-php/
When I run the script, it shows me a "Connect Me!" message and when I click on it, the browser ask my permition to access my google account. After I agree, it would must redirect me to the address in setRedirectUri, in HTTPS mode. But google api redirect me the same url but in http mode.
Some idea?
Thanks a lot!
I believe all is working, but after successful authentication on https your own code redirects you to a cleaned URL on plain http. Check the sample code that you copied after receiving and exchanging the code ("Step 2") and change the construction of the URL so that it uses https instead of https.
I'm trying to do some initial testing in my local environment with box.com api. I've registered the api key and I'd like to put a localhost url in redirect uri form field but it seems like it only allows https (which I don't have in localhost). Message returned:
OAuth2 redirect URL must specify a valid URL and must not be http://
The requirement for the https is a good thing. While you are still in dev it would still be an active auth token transmitted in plain text if sent to http:// which someone could grab and use to mess with your box.net account.
You are going to need to generate a self signed certificate and install that locally to allow for this to work.
How can I create a self-signed cert for localhost?
Another option to further enhance this would be to actually buy the SSL that you are going to need for this project when it goes live and use a local dns redirect via your hosts file to load the domain off your local dev machine as opposed to the live server.
Box has updated itself to allow localhost to be http://. For other URIs, you need https://
I can call the HTTP web service but when the same service is HTTPS it throws error that it cannot be called. I am invoking it from iOS application. Do I need to pass some additional header fields related to HTTPS.
UPDATE (SOLUTION):
Seems like it just needed the HOST header parameter.
if you are not passing any authorization parameters in any way to the service and it is just a url: "https://www.xxxxxx.com/dev/tools/search=?" the issue is from server side authentication certificate. they need to allow the request to be taken in from server's end by configuring server authentication certificate.