The jenkins template doesn't include a certificate anymore, so either online needs to update to a new template, or something else is misconfigured in online such that the router certs are bad:

https://github.com/openshift/origin/blob/master/examples/jenkins/jenkins-persistent-template.json

This has been fixed in DevPreview INT already (3.4) and will be applied to DevPrevew Prod as a hotfix.

Verified in the INT environment, the route can be accessed, but it prompt "java.lang.Exception: State is invalid" when having been tried to authorize that with github.

The full log is attached.

I cannot reproduce the problem.  Here are the steps I followed:

1. Log in to dev-preview-int at <https://console.preview.openshift.com>.
2. At the console, click "New Project", enter a valid name, display name, and description, and click "Create".
3. Enter "jenkins" into the search field and click "Select" under "Jenkins (Persistent)".
4. Leave the default configuration values and click "Create".
5. On the command line, run `while :; do oc logs dc/jenkins -f; sleep 1; done`.
6. Wait for the "INFO: Jenkins is fully up and running" log message (it appears after about 46 seconds).
7. Back in the console, navigate "Go to overview" -> "Applications" -> "Routes" and click the route.
8. Click "Login with OpenShift" at the prompt from Jenkins.
9. Click "Login with github" at the prompt from OAuth.
10. If prompted, grant the GitHub access permissions requested by Jenkins (the prompt was skipped the second time I ran through these steps).
11. In Jenkins, navigate "Manage Jenkins" -> "System Log" -> "All Jenkins Logs".

Based on comment 3, I expect to see a Java exception and backtrace in the `oc logs` output after Step 10, but I see no errors the `oc logs` output, nor in the logs displayed by Step 11.

Note that the original description mentions an "Instant Apps" choice when browsing the catalog, but I see no such option, so instead I typed "jenkins" into the search field in order to get the "Jenkins (Persistent)" option for the template named "jenkins-persistent".  Is it possible you got a different template and image? The "jenkins-persistent" template I got uses the following image:

% oc get dc/jenkins --template=$'{{(index .spec.template.spec.containers 0).image}}\n'
registry.ops.openshift.com/openshift3/jenkins-2-rhel7@sha256:27c8e7dd29e5663d9e11ffb573f49c9c9aaac547d657e3f1f78a5cecfa824544

For the record, I see the following on "?" -> "About":

    Version
    
    OpenShift Master:
        v3.4.0.38 (online version 3.4.0.11)
    Kubernetes Master:
        v1.4.0+776c994

3.4.0.11 was built and deployed 2017-01-04, as was the image deployed by the jenkins-persistent template, so it looks like we should be using the same template and image.

Perhaps there some relevant difference between our Dev Preview or GitHub credentials, but before we look into that, let's check some simpler things.

Can you confirm that we ware using the same image and steps?

Do you see the problem consistently if you run through the above steps 2 or 3 times, or is it intermittent?

All steps I followed are same as your steps , and the jenkins image is same too.
However, today I try a few times , the problem occurred again, so it is intermittent.

After clicking "LOGIN WITH GITHUB" the page "Authorize Access" will be open, at which point the problem appears. We find if the "Authorize Access" can be shown successfully it will work well.

The dc json file and the pod's log is saved and attached. I find some warnings about websocket, which maybe results the problem. 

Would you help check the log? it maybe is helpful to find the the reason.

Created attachment 1238978 [details]
jenkins pod logs

Created attachment 1238979 [details]
deploymentconfig

And please ignore the information about user "ychww" in the jenkins logs , it is another github user just for testing.

Miciah asked for an assist.  I don't have a conclusion, but can possible progress the debug / diagnosis some.

Regarding the exception in #Comment 3 and log in #Comment 4, here is the relevant stack trace snippet:

java.lang.Exception: State is invalid
	at org.kohsuke.stapler.HttpResponses.error(HttpResponses.java:83)
	at org.openshift.jenkins.plugins.openshiftlogin.OAuthSession.doFinishLogin(OAuthSession.java:106)
	at org.openshift.jenkins.plugins.openshiftlogin.OpenShiftOAuth2SecurityRealm.doFinishLogin(OpenShiftOAuth2SecurityRealm.java:742)


The relevant piece of the code in the plugin is the `doFinishLogin` method here:  https://github.com/openshift/jenkins-openshift-login-plugin/blob/master/src/main/java/org/openshift/jenkins/plugins/openshiftlogin/OAuthSession.java#L96-L116

This is the end of the http redirect ping pong flow that occurs between Jenkins and OpenShift Oauth support running in the OpenShift master.

In `doFinishLogin` the "State is invalid" is getting cited when the state in the auth code response does not equal the state set in the auth code request earlier in the oauth redirect ping pong flow that occurs.  As an FYI, the state on the auth code request is set here:  https://github.com/openshift/jenkins-openshift-login-plugin/blob/master/src/main/java/org/openshift/jenkins/plugins/openshiftlogin/OAuthSession.java#L88

The auth code request state (the `uuid` field) is state stored in the HttpSession in Jenkins for the given login attempt when the redirect ping/pong starts.  The redirect back to Jenkins should result in that HttpSession being accessed.

On the surface, it would appear diagnosis in minimally needed on the openshift oauth side.

I've cc:ed Jordon, Mo, and Clayton to chime in.  I suspect the next course of debug is to analyze the master logs at the time of the failure and see what is going on in the OAuth layer when this occurs.  Does that sound right?  I also wonder if the identity provider used for online (Miciah tells me it is "Keycloak") has any bearing here.

can you capture all the network requests the browser sees (in chrome, view developer tools, network tab, check "preserve log", then walk through a login flow)

I'd want to see the original OAuth redirect from jenkins, all the intermediate requests, and the final return URL directing back to jenkins

Zhao, could you gather the information requested by Jordan in comment 12? I still have not reproduced the failure (having tried with Chrome 57.0.2970 and Firefox 45.4.0).

I have gathered the log with developer tools in version 53.0.2785.143 chrome . The logs are saved with har format and have been attached. There are two log files ,which belong to different projects.

Created attachment 1239840 [details]
jenkins-yasun-int.1ec1.dev-preview-int.openshiftapps.com.har

Created attachment 1239841 [details]
jenkins-jjj.1ec1.dev-preview-int.openshiftapps.com.har

Took a peek at the attachment from #Comment 15 and the URL that came back from openshift oauth was indicative of an error on the oauth provider running in openshift master:

"https://jenkins-yasun-int.1ec1.dev-preview-int.openshiftapps.com/securityRealm/finishLogin?error=server_error&error_description=The+authorization+server+encountered+an+unexpected+condition+that+prevented+it+from+fulfilling+the+request."

Same looking URL for the attachment from #Comment 16

The master's log will be more useful here as that error message serves as a general mask for a variety of different internal oauth errors.

The latest problem appears be the same problem reported in bug 1413863.

Bug 1413863 has been VERIFIED, so the issue in comment 28 should be resolved.

Moving to QA based on comment above.

Jenkins app can be accessed normally using image:

sha256:66eea68ebc701a13527a4172feb2c4c0c9acda09efaa59821393498121d97ae0

Move to verified, thanks!