galasa-dev / managers Goto Github PK

z/OSMF requires X-CSRF-ZOSMF-HEADER to be passed in all HTTP requests. Seems this header is not passed by default by ZosmfZosDatasetImpl while using the code samples mentioned for z/OS File

ERROR d.g.z.i.ZosmfRestApiProcessor - Problem with zOSMF request dev.galasa.zosmf.ZosmfException: Unexpected HTTP status code: 403 at dev.galasa.zosmf.internal.ZosmfImpl.get(ZosmfImpl.java:113) at dev.galasa.zosmf.internal.ZosmfRestApiProcessor.sendRequest(ZosmfRestApiProcessor.java:74) at dev.galasa.zosfile.zosmf.manager.internal.ZosmfZosDatasetImpl.exists(ZosmfZosDatasetImpl.java:264)

Is there a way to explicitly set this header ? or even pass instance of zosmf manager which already provides a way to set headers ?
How can the file manager be used without setting this header when z/OSMF requires it ?

GALASA version : 0.14.0

Thanks,
Vibhor

Please write a JUnit test class that suggest what you expect from LogScanner implementation when you had some time

CEMT inquire method not cleaning the terminal after being called from different CEDA IVT methods.

When the MQ manager is used on Windows, we are getting the following error message:

5/08/2022 14:34:32.695 INFO  main [dev.galasa.mq](http://dev.galasa.mq/).internal.MessageQueueImpl.archiveMessage - Unable to log message for a queue
java.nio.file.InvalidPathException: Illegal char <:> at index 51: mq/messages/clearQueue/RAFDA.TESTQ/outbound/message:4

The queue is declared as:

	@Queue(archive = true, name = "RAFDA.TESTQ", queueMgrTag = "PRIMARY")
	public IMessageQueue queue;

When archive = false, the problem does not occur.
The same code works well on macOS. It seems that : that is used in the path for archiving is not valid in the Windows path. Replacing it with a different character can be a good solution.

Currently core manager provides this interface:
ICredentials getCredentials(@NotNull String credentialsId) throws CoreManagerException;

However the ICredentials object needs to be tested to see if it's a sub-class before it can be used (most often for a username and password)

Please add a new method that returns a ICredentialsUsernamePassword object as well