I am facing an issue when I am scripting the redirects in nGrinder (Script written in Groovy in Eclipse; Eclipse integrated with Groovy plugin) for the URL: https://winterfell-sbo-sbo-test-cso-web-mta.cfapps.sap.hana.ondemand.com/sites
Attached is the Eclipse log (Page #11, #12, #13) for your reference and below is the explanation on the issue.
Step#1
I fire a HTTP GET request on https://winterfell-sbo-sbo-test-cso-web-mta.cfapps.sap.hana.ondemand.com/sites.
This automatically follows redirects and then lands on to the Login Page: https://winterfell.authentication.sap.hana.ondemand.com/login
Step#2
I fire another HTTP GET request on 'https://winterfell.authentication.sap.hana.ondemand.com/saml/discovery?returnIDParam=idp&entityID=winterfell.canary&idp=winterfell-metadata&isPassive=true
This doesn't automatically redirect to "Location" header -> https://winterfell.authentication.sap.hana.ondemand.com/saml/login/alias/winterfell.canary?disco=true&idp=xs2security.accounts400.ondemand.com
Refer to the screenshot for more information.
Instead it gets redirected to https://winterfell.authentication.sap.hana.ondemand.com/login
We tried to capture and set the csrf cookie for the GET request of https://authentication.sap.hana.ondemand.com/saml/discovery?returnIDParam=idp&entityID=winterfell.canary&idp=winterfell-metadata&isPassive=true -> but still it isn't working as expected
Colleague was able to make this work in JMeter. So we are trying to simulate this in nGrinder by setting "followRedirects" to true and it isn't working as expected.
Since in Step#2, it is not picking up the location of the response header and redirecting back to "/login" page, what could be the possible reasons for this behavior?
we checked if xsuaa is working fine. On executing the request in Postman, everything worked as expected. Curl works well.
Related
I have a web application running on Wildfly 26 that uses SSE broadcasting and works correctly with http. However, when I switch to using an https endpoint, I get Wildfly log entries of:
WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-1)
RESTEASY002186: Failed to set servlet request into asynchronous mode,
server sent events may not work
This happens with each registration attempt of the https endpoint but I never see this when registering with the http endpoint.
Testing with curl against the http endpoint results in curl waiting for events to show up (and keeps printing them out as it receives them) until I quit. Using curl to test the https endpoint, I will see the same headers I got from the http endpoint, namely:
HTTP/1.1 200 OK
Connection: keep-alive
Transfer-Encoding: chunked
Content-Type: text/event-stream
But after printing out my registration successful event, curl seems to believe the stream is closed and exits -- giving me my command prompt back.
My #GET MediaType.SERVER_SENT_EVENTS registration endpoint will create an OutboundSseEvent and send it to the SseEventSink to acknowledge successful registration to my SseBroadcaster instance (this is the event curl sees and prints before exiting). I then log a registration successful message before exiting the method. All of this appears to work correctly for both http and https but the stream doesn't stay open once the request endpoint completes because of the failure to run asynchronously as outlined above.
I have not found information on the causes and/or workaround solutions for my RESTEASY002186 problem. I posted a question on this issue last week using the Wildfly Google Group (https://groups.google.com/g/wildfly/c/SO2eHdvMEko) but thought I would try a wider audience since this doesn't seem to be a commonly experienced condition. I don't see any indications during initialization that WildFly will be unable to use asynchronous mode, it just complains when it tries and fails... Any help would be greatly appreciated!
Edit 6/6/2022
The code is running on an isolated network so I can't just cut/paste the code here, but I gutted the resources file to a bare minimum -- just leaving enough for the client to be able to register. The problem remains unchanged. The code is now essentially:
#Path("sse")
public class SseResources {
#GET
#Produces(MediaType.SERVER_SENT_EVENTS)
public void listen(#Context Sse sse, #Context SseEventSink sseEventSink) {
SseRegComplete regComplete = new SseRegComplete("sse-server");
OutboundSseEvent event = sse.newEventBuilder().
name(regComplete.getType().toString()).
id(regComplete.getEventId()).
mediaType(MediaType.APPLICATION_JSON_TYPE).
data(SseRegComplete.class, regComplete).
comment("Event Stream Registration Completed Successfully").
build();
sseEventSink.send(event);
}
}
Before the above simplified code, I had declared the resource as #ApplicationScoped, had Sse injected into it, and kept a reference to the SseBroadcaster so I could use it whenever an event would come in. I was catching the events to broadcast by using an #Observes method (which I also got rid of). I was calling register(sseEventSink) on the SseBroadcaster in the listen method so I could later call broadcast(outboundEvent) whenever I had updates to publish. I got rid of all that just to see if I could get the stream to stay open but to no avail. I still get the RESTEASY002186 message and curl still exits after printing out the regComplete event sent to it in the code above.
Edit 6/7/2022
Yesterday I was able to get my code working in a new vanilla Wildfly 26 install using an https endpoint URL by following these configuration instructions. Something I hadn't mentioned in the original post is that I am trying to add SSE functionality to an already existing app. It is several years old and we actually moved to Wildfly 26 about 6 months ago because of the log4j vulnerability in the earlier version of Wildfly we were using. I suspect that the problem is related to either our Wildfly configuration (perhaps because old settings were brought over that shouldn't have been) or some 3rd party dependency that is preventing Wildfly from using asynchronous mode.
We are using Shiro for authentication and authorization against an LDAP server -- perhaps Shiro has some hooks into the Wildfly runtime that are causing issues? After initial login, we use a session cookie in all subsequent calls. That is a difference from my test server but I don't think it is relevant because the call definitely passed authentication before executing the registration code. The only other thing that comes to mind right now is our web app ships with LogBack and tells Wildfly not to use the default logging framework.
I plan to start today by comparing the two standalone.xml files to see if anything jumps out at me as being fundamentally different. Is there anything else I should be checking for differences (I think there is a domain.xml file somewhere...)?
Edit 6/14/2022
This definitely has something to do with Shiro being in the loop. When I edit the web.xml file to have Shiro's filter-mapping url-pattern to not include the SSE endpoint, everything works as expected.
This seems to be on a very new topic because the "stitch" or "mongodb-stitch" tags do not exist yet.
I have a mongodb altas cluster on cloud.mongodb.com. The page https://docs.mongodb.com/stitch/auth/email-auth/ only teaches how to do things with JS but I don't have server side JS on hand. Instead I tried to figure out how to do things with the StitchClient on the Android API.
I was able to register an email/password pair using StitchClient.register(email,pwd) and got an email from no-reply+stitch#mongodb.com with the token/tokenId. I copied them and used StitchClient.emailConfirm(token, tokenId) but failed. The error was:
Unexpected response code 404 for https://stitch.mongodb.com/api/client/v1.0/app/APP-ID/auth/local/userpass/confirm
which sounds strange! I opened a browser and paste that in the URL and got 404 too. I even did
curl --data "token=432...345&tokenId=435..334" https://stitch.mongodb.com/api/client/v1.0/app/APP-ID/auth/local/userpass/confirm
and still got 404.
Is this a bug or an outage of the stitch.mongodb.com server?
I created a simple REST on Kitura. When I run it on your Mac, it works fine. GET / POST / PUT / DELETE are executed. When I run it on bluemix, GET method works correctly, but the POST is wrong. In response to the POST I should return JSON to create an object and returns a response with the text "unknown" in the body. Then, at my request any returns "unknown". No errors in the logs there. What could it be?
Kitura version 0.15.6, swift-DEVELOPMENT-SNAPSHOT-2016-05-03-a
This was a bug in the Linux implementation of SwiftyJSON that incorrectly marked UInts as invalid.
I fixed this and pushed a new version: 7.0.4
This will now work once you update your dependencies.
This problem seems to exist on a specific server. All other servers are working ok.
Background: The website is basically Forms Auth but there's an asmx that manually requires Basic Auth.
I have two C# client.
When invoking using SOAP (asmx client proxy) with basic auth credentials - all is well.
When invoking using WebClient or WebRequest with the same basic auth credentials, I get 401.5.
The folders have "Everyone" set to them.
When setting up iis trace, I see a very weird behavior. The request arrives with the correct Basic auth header. But further down the trace I see the following:
GENERAL_REQUEST_HEADERS
Headers="Connection: Keep-Alive
Content-Length: 68
Content-Type: application/json
Authorization: Kerberos
Expect: 100-continue
Host: 1.2.3.4
The Kerberos seems very weird. It is as if the request headers changed throughout the process, and perhaps that explains the 401.5.
Again, I would like to stress out that on other servers there's no problem with both clients. The only difference I can think of is that the problematic server is a DC. But if that is a problem then why is the SOAP client working well?
Any ideas?
Progress!
After some debugging I noticed that Application_AuthenticateRequest was fired twice for every request. The first time with Basic auth as I expected and the second time with the Kerberos!
After googling I found this:
http://forums.asp.net/t/1868629.aspx?HttpModule+triggered+two+times+for+request+to+URL+without+default+document
Seems like for extensionless urls those events might fire multiple times, depending on the configured Extensionless urls.
Going back to the trace I noticed that in the non-working server the trace shows usage of ExtensionlessUrl-ISAPI-4.0_64bit, and in the working servers no such entry existed. After comparing the two IIS I noticed that the non-working IIS had ExtensionlessUrl-ISAPI-4.0_64bit configured whereas in the working IIS there was ExtensionlessUrl**Handler**-ISAPI-4.0_64bit (note the "handler"). I compared the dlls involved and the working server had a newer aspnet_isapi.dll. I assume that this is an updated extensionless url handler. I suppose an upgrade to IIS or .NET might install a later version, but for now I tried to remove the ExtensionlessUrl-ISAPI-4.0_xxbit like so:
<remove name="ExtensionlessUrl-ISAPI-4.0_32bit" />
<remove name="ExtensionlessUrl-ISAPI-4.0_64bit" />
And it worked! Now there is only a single Application_AuthenticateRequest.
The non-working version that had this in the trace:
OldHandlerName="", NewHandlerName="ExtensionlessUrl-ISAPI-4.0_64bit", NewHandlerModules="IsapiModule", NewHandlerScriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll", NewHandlerType=""
Now changed to:
OldHandlerName="", NewHandlerName="WebServiceHandlerFactory-ISAPI-4.0_64bit", NewHandlerModules="IsapiModule", NewHandlerScriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll", NewHandlerType=""
Hopefully that's the end of it. Additional testing still required.
I would appreciate if someone can write how to upgrade IIS dlls to a later version. Is this an upgrade to .NET or is there a specific KB update that is downloaded with Windows Update?
I've created a Facebook page (with WordPress) but I can't get it to work in Facebook.
The original page is working fine at: (just add the https to see the SSL version)
http://copywriting.com/fb/fanpage/pueblito-reserve/
However, when I load it into Facebook, the SSL version works fine, but the regular http version gives back a 500 Internal Server Error.
Regular FB tab (with the 500 error): (add the https and it works fine)
http://www.facebook.com/PueblitoEscondido/app_382773098443040
How can this be solved?
How can this be solved?
By looking into your server’s logfiles to see what caused this error …