[JIRA] (JENKINS-60095) Windows paths

37 views
Skip to first unread message

will@willwh.com (JIRA)

unread,
Nov 7, 2019, 2:16:02 PM11/7/19
to jenkinsc...@googlegroups.com
William Hetherington created an issue
 
Jenkins / Bug JENKINS-60095
Windows paths
Issue Type: Bug Bug
Assignee: William Hetherington
Components: saml-plugin
Created: 2019-11-07 19:15
Priority: Minor Minor
Reporter: William Hetherington

The strings `SP_METADATA_FILE_NAME` and `IDP_METADATA_FILE_NAME` have hardcoded `/`'s in them which means `getIDPMetadataFilePath` and `getSPMetadataFilePath` do not return valid paths in windows.

Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo

will@willwh.com (JIRA)

unread,
Nov 7, 2019, 2:16:02 PM11/7/19
to jenkinsc...@googlegroups.com
William Hetherington updated an issue
Change By: William Hetherington
The strings ` * SP_METADATA_FILE_NAME ` * and ` * IDP_METADATA_FILE_NAME ` * have hardcoded ` * / ` * 's in them which means ` * getIDPMetadataFilePath ` ()* and ` * getSPMetadataFilePath ` ()* do not return valid paths in windows.

will@willwh.com (JIRA)

unread,
Nov 7, 2019, 2:21:02 PM11/7/19
to jenkinsc...@googlegroups.com
William Hetherington commented on Bug JENKINS-60095
 
Re: Windows paths

This change has no tests, I am replacing a "/" in a string in favour of File.separator, so that this will work on windows.

kuisathaverat@gmail.com (JIRA)

unread,
Dec 1, 2019, 12:08:03 PM12/1/19
to jenkinsc...@googlegroups.com

kuisathaverat@gmail.com (JIRA)

unread,
Dec 1, 2019, 12:08:03 PM12/1/19
to jenkinsc...@googlegroups.com
Status: In Review Fixed but Unreleased
Resolution: Fixed

kuisathaverat@gmail.com (JIRA)

unread,
Dec 1, 2019, 12:08:04 PM12/1/19
to jenkinsc...@googlegroups.com
Status: Open In Progress

will@willwh.com (JIRA)

unread,
Dec 13, 2019, 12:57:03 PM12/13/19
to jenkinsc...@googlegroups.com
Change By: William Hetherington
Resolution: Fixed
Status: Fixed but Unreleased Reopened

will@willwh.com (JIRA)

unread,
Dec 13, 2019, 1:21:04 PM12/13/19
to jenkinsc...@googlegroups.com
 
Re: Windows paths

Hi Ivan,

I don't have a SAML configuration I can use for testing until next week, (I'm waiting on an Okta sandbox being rebuilt), but, I think this is not sufficient to fix this in Windows.

public HttpResponse doMetadata(StaplerRequest request, StaplerResponse response) {
    return new SamlSPMetadataWrapper(getSamlPluginConfig(), request, response).get();     
}

I think that the path for the metadata that is being passed is incorrect.
 
Without an active session, Jenkins does not properly redirect to Okta, when the plugin is deployed on a Windows host, and I see the following in the logs:
 

[id=14] INFO o.o.c.c.InitializationService#initialize: Initializing OpenSAML using the Java Services API
[id=14] INFO o.o.c.c.InitializationService#initialize: Initializing OpenSAML using the Java Services API
[id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#<init>: Using SP entity ID Jenkins-users
[id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Writing sp metadata to C:\Jenkins\saml-sp-metadata.xml
[id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Attempting to create directory structure for C:\Jenkins
[id=14] WARNING o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Could not construct the directory structure for SP metadata C:\Jenkins\saml-sp-metadata.xml
[id=14] INFO o.p.s.c.DefaultSignatureSigningParametersProvider#build: Created signature signing parameters.

 

My guess is, the path being passed is `C:\Jenkins\Windows` - and this is ultimately causing pac4j to properly find the `saml-sp-metadata.xml`:

https://github.com/jenkinsci/saml-plugin/blob/master/src/main/java/org/jenkinsci/plugins/saml/SamlSPMetadataWrapper.java#L42-L44

 

Based on this failing: https://github.com/pac4j/pac4j/blob/f82b377690f400f518145a4d543acb187d4dd4ac/pac4j-saml/src/main/java/org/pac4j/saml/metadata/SAML2ServiceProviderMetadataResolver.java#L134-L160

 

Do you have any thoughts here? I will try to update this issue as soon as I have Idp config for testing, some time next week.

 

will@willwh.com (JIRA)

unread,
Dec 13, 2019, 1:22:02 PM12/13/19
to jenkinsc...@googlegroups.com
Hi Ivan,

I don't have a SAML configuration I can use for testing until next week, (I'm waiting on an Okta sandbox being rebuilt), but, I think this is not sufficient to fix this in Windows.
{code:java}

public HttpResponse doMetadata(StaplerRequest request, StaplerResponse response) {
    return new SamlSPMetadataWrapper(getSamlPluginConfig(), request, response).get();     
}{code}

I think that the path for the metadata that is being passed is incorrect.
 
Without an active session, Jenkins does not properly redirect to Okta, when the plugin is deployed on a Windows host, and I see the following in the logs:
 
{code:java}

[id=14] INFO o.o.c.c.InitializationService#initialize: Initializing OpenSAML using the Java Services API
[id=14] INFO o.o.c.c.InitializationService#initialize: Initializing OpenSAML using the Java Services API
[id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#<init>: Using SP entity ID Jenkins-users
[id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Writing sp metadata to C:\Jenkins\saml-sp-metadata.xml
[id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Attempting to create directory structure for C:\Jenkins
[id=14] WARNING o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Could not construct the directory structure for SP metadata C:\Jenkins\saml-sp-metadata.xml
[id=14] INFO o.p.s.c.DefaultSignatureSigningParametersProvider#build: Created signature signing parameters.{code}
 

My guess is, the path being passed is `C:\Jenkins\
Windows saml-sp-metadata.xml ` - and this is ultimately causing pac4j to properly find the `saml-sp-metadata.xml`: (it should probably be like `C:\\Jenkins\\saml-sp-metadata.xml`

will@willwh.com (JIRA)

unread,
Dec 13, 2019, 1:23:02 PM12/13/19
to jenkinsc...@googlegroups.com
Hi Ivan,

I don't have a SAML configuration I can use for testing until next week, (I'm waiting on an Okta sandbox being rebuilt), but, I think this is not sufficient to fix this in Windows.
{code:java}
public HttpResponse doMetadata(StaplerRequest request, StaplerResponse response) {
    return new SamlSPMetadataWrapper(getSamlPluginConfig(), request, response).get();     
}{code}
I think that the path for the metadata that is being passed is incorrect.
 
Without an active session, Jenkins does not properly redirect to Okta, when the plugin is deployed on a Windows host, and I see the following in the logs:
 
{code:java}
[id=14] INFO o.o.c.c.InitializationService#initialize: Initializing OpenSAML using the Java Services API
[id=14] INFO o.o.c.c.InitializationService#initialize: Initializing OpenSAML using the Java Services API
[id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#<init>: Using SP entity ID Jenkins-users
[id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Writing sp metadata to C:\Jenkins\saml-sp-metadata.xml
[id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Attempting to create directory structure for C:\Jenkins
[id=14] WARNING o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Could not construct the directory structure for SP metadata C:\Jenkins\saml-sp-metadata.xml
[id=14] INFO o.p.s.c.DefaultSignatureSigningParametersProvider#build: Created signature signing parameters.{code}
 

My guess is, the path being passed is `C:\Jenkins\saml-sp-metadata.xml` - and this is ultimately causing pac4j to properly find the `saml-sp-metadata.xml`: (it should probably be like `C:\\Jenkins\\saml-sp-metadata.xml`

will@willwh.com (JIRA)

unread,
Dec 13, 2019, 1:23:02 PM12/13/19
to jenkinsc...@googlegroups.com
Hi Ivan,

I don't have a SAML configuration I can use for testing until next week, (I'm waiting on an Okta sandbox being rebuilt), but, I think this is not sufficient to fix this in Windows.
{code:java}
public HttpResponse doMetadata(StaplerRequest request, StaplerResponse response) {
    return new SamlSPMetadataWrapper(getSamlPluginConfig(), request, response).get();     
}{code}
I think that the path for the metadata that is being passed is incorrect.
 
Without an active session, Jenkins does not properly redirect to Okta, when the plugin is deployed on a Windows host, and I see the following in the logs:
 
{code:java}
[id=14] INFO o.o.c.c.InitializationService#initialize: Initializing OpenSAML using the Java Services API
[id=14] INFO o.o.c.c.InitializationService#initialize: Initializing OpenSAML using the Java Services API
[id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#<init>: Using SP entity ID Jenkins-users
[id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Writing sp metadata to C:\Jenkins\saml-sp-metadata.xml
[id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Attempting to create directory structure for C:\Jenkins
[id=14] WARNING o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Could not construct the directory structure for SP metadata C:\Jenkins\saml-sp-metadata.xml
[id=14] INFO o.p.s.c.DefaultSignatureSigningParametersProvider#build: Created signature signing parameters.{code}
 

My guess is, the path being passed is *C:\Jenkins\saml-sp-metadata.xml* - and this is ultimately causing pac4j to properly find the *saml-sp-metadata.xml*: (it should probably be like *C:\\Jenkins\\ ** saml-sp-metadata.xml*  

will@willwh.com (JIRA)

unread,
Dec 13, 2019, 1:23:03 PM12/13/19
to jenkinsc...@googlegroups.com
Hi Ivan,

I don't have a SAML configuration I can use for testing until next week, (I'm waiting on an Okta sandbox being rebuilt), but, I think this is not sufficient to fix this in Windows.
{code:java}
public HttpResponse doMetadata(StaplerRequest request, StaplerResponse response) {
    return new SamlSPMetadataWrapper(getSamlPluginConfig(), request, response).get();     
}{code}
I think that the path for the metadata that is being passed is incorrect.
 
Without an active session, Jenkins does not properly redirect to Okta, when the plugin is deployed on a Windows host, and I see the following in the logs:
 
{code:java}
[id=14] INFO o.o.c.c.InitializationService#initialize: Initializing OpenSAML using the Java Services API
[id=14] INFO o.o.c.c.InitializationService#initialize: Initializing OpenSAML using the Java Services API
[id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#<init>: Using SP entity ID Jenkins-users
[id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Writing sp metadata to C:\Jenkins\saml-sp-metadata.xml
[id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Attempting to create directory structure for C:\Jenkins
[id=14] WARNING o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Could not construct the directory structure for SP metadata C:\Jenkins\saml-sp-metadata.xml
[id=14] INFO o.p.s.c.DefaultSignatureSigningParametersProvider#build: Created signature signing parameters.{code}
 

My guess is, the path being passed is ` * C:\Jenkins\saml-sp-metadata.xml ` * - and this is ultimately causing pac4j to properly find the ` * saml-sp-metadata.xml ` * : (it should probably be like ` * C:\\Jenkins\\saml-sp-metadata.xml ` *

will@willwh.com (JIRA)

unread,
Dec 13, 2019, 1:24:03 PM12/13/19
to jenkinsc...@googlegroups.com
Hi Ivan,

I don't have a SAML configuration I can use for testing until next week, (I'm waiting on an Okta sandbox being rebuilt), but, I think this is not sufficient to fix this in Windows.
{code:java}
public HttpResponse doMetadata(StaplerRequest request, StaplerResponse response) {
    return new SamlSPMetadataWrapper(getSamlPluginConfig(), request, response).get();     
}{code}
I think that the path for the metadata that is being passed is incorrect.
 
Without an active session, Jenkins does not properly redirect to Okta, when the plugin is deployed on a Windows host, and I see the following in the logs:
 
{code:java}
[id=14] INFO o.o.c.c.InitializationService#initialize: Initializing OpenSAML using the Java Services API
[id=14] INFO o.o.c.c.InitializationService#initialize: Initializing OpenSAML using the Java Services API
[id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#<init>: Using SP entity ID Jenkins-users
[id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Writing sp metadata to C:\Jenkins\saml-sp-metadata.xml
[id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Attempting to create directory structure for C:\Jenkins
[id=14] WARNING o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Could not construct the directory structure for SP metadata C:\Jenkins\saml-sp-metadata.xml
[id=14] INFO o.p.s.c.DefaultSignatureSigningParametersProvider#build: Created signature signing parameters.{code}
 

My guess is, the path being passed is *C:\Jenkins\saml-sp-metadata.xml* - and this is ultimately causing pac4j to properly find the *saml-sp-metadata.xml*: ( it should probably be like *C: Windows paths usually want escaped \ \Jenkins\\**saml-sp-metadata.xml* 's ?)  

will@willwh.com (JIRA)

unread,
Dec 13, 2019, 1:25:02 PM12/13/19
to jenkinsc...@googlegroups.com
Hi Ivan,

I don't have a SAML configuration I can use for testing until next week, (I'm waiting on an Okta sandbox being rebuilt), but, I think this is not sufficient to fix this in Windows.
{code:java}
public HttpResponse doMetadata(StaplerRequest request, StaplerResponse response) {
    return new SamlSPMetadataWrapper(getSamlPluginConfig(), request, response).get();     
}{code}
I think that the path for the metadata that is being passed is incorrect.
 
Without an active session, Jenkins does not properly redirect to Okta, when the plugin is deployed on a Windows host, and I see the following in the logs:
 
{code:java}
[id=14] INFO o.o.c.c.InitializationService#initialize: Initializing OpenSAML using the Java Services API
[id=14] INFO o.o.c.c.InitializationService#initialize: Initializing OpenSAML using the Java Services API
[id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#<init>: Using SP entity ID Jenkins-users
[id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Writing sp metadata to C:\Jenkins\saml-sp-metadata.xml
[id=14] INFO o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Attempting to create directory structure for C:\Jenkins
[id=14] WARNING o.p.s.m.SAML2ServiceProviderMetadataResolver#resolve: Could not construct the directory structure for SP metadata C:\Jenkins\saml-sp-metadata.xml
[id=14] INFO o.p.s.c.DefaultSignatureSigningParametersProvider#build: Created signature signing parameters.{code}
 

My guess is, the path being passed is *C:\Jenkins\saml-sp-metadata.xml* - and this is ultimately causing pac4j to properly not find the *saml-sp-metadata.xml*: (Windows paths usually want escaped \'s ?) 

kuisathaverat@gmail.com (JIRA)

unread,
Dec 15, 2019, 8:01:02 AM12/15/19
to jenkinsc...@googlegroups.com
Ivan Fernandez Calvo commented on Bug JENKINS-60095
 
Re: Windows paths

this is a warning not an error, it is normal, I cannot rid of it because it is in the pac4j library. Your problem should be other, enable verbosely log (https://github.com/jenkinsci/saml-plugin/blob/master/doc/TROUBLESHOOTING.md) and see if the SAML request is sent, if so, the redirection has to be done by the browser.

kuisathaverat@gmail.com (JIRA)

unread,
Dec 15, 2019, 8:04:02 AM12/15/19
to jenkinsc...@googlegroups.com
Change By: Ivan Fernandez Calvo
Status: Closed Fixed but Unreleased

kuisathaverat@gmail.com (JIRA)

unread,
Dec 15, 2019, 8:04:03 AM12/15/19
to jenkinsc...@googlegroups.com
Ivan Fernandez Calvo edited a comment on Bug JENKINS-60095
 
Re: Windows paths
this is a warning not an error, it is normal, I cannot rid of it because it is in the pac4j library. Your problem should be other, enable verbosely log (https://github.com/jenkinsci/saml-plugin/blob/master/doc/TROUBLESHOOTING.md) and see if the SAML request is sent, if so, the redirection has to be done by the browser. To avoid mix this issue with you another issue, please open a thread on the google groups with the details of the login process (what steps are done in the verbose log), I would help you there. I will close this issue.

kuisathaverat@gmail.com (JIRA)

unread,
Dec 15, 2019, 8:04:03 AM12/15/19
to jenkinsc...@googlegroups.com
Ivan Fernandez Calvo closed an issue as Fixed
Status: Reopened Closed
Resolution: Fixed

kuisathaverat@gmail.com (JIRA)

unread,
Jan 12, 2020, 1:39:02 PM1/12/20
to jenkinsc...@googlegroups.com
Status: Fixed but Unreleased Closed
Released As: saml-1.1.15

kuisathaverat@gmail.com (JIRA)

unread,
Jan 12, 2020, 1:44:03 PM1/12/20
to jenkinsc...@googlegroups.com
Ivan Fernandez Calvo updated an issue
Released As: saml-1.1. 15 5
Reply all
Reply to author
Forward
0 new messages