HTTP/1.1 401
X-message-code: PWD_WRONG
WWW-Authenticate: Basic realm="SAP HANA Cloud Platform"
Transfer-Encoding: chunked
Date: Fri, 18 Oct 2019 11:06:40 GMT
Server: SAP
Set-Cookie: BIGipServerl4097iflmapavrhcip.factory.customdomain=!Nu8jU3HA2IxyvHz2sXeD7QV2Vba36noiDcfL3aW4P6aJ3bFLqxzKN/NcLEGyHmjUFAx3qBE6h10zBwU=; path=/; Httponly; Secure; httponly; secure
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Some times, the site may encode the password at the frontend and then send it to the server which can decode it. Check with your dev team if the password is encoded by a javascript before being sent
Logically X-message-code: PWD_WRONG indicates that you provided wrong password. Double check your credentials in the HTTP Authorization Manager, it might be the case you made a typo, even characters which are not visible like whitespace or line break matter.
Looking into Create new user on Cloud Integration thread:
The message displayed (PWD_WRONG) means the member has never logged into the SCP Account and no credentials were provided to it.
Also looking here it might be the case you need to supply an appropriate client-side certificate
Related
After logging in I am setting some cookies, which works in FF, Chrome, Edge etc. However for some reason, Samsung Internet Browser seems to be ignoring my cookies.
I've got cookies enabled, and it is accepting cookies from other sites, but I can't figure out why it won't accept them. I've got this capture from my server:
HTTP/1.1 200 OK
Content-Type: application/json
Set-Cookie: token=e1c137y8WEZItXVWExXBWRyQl9mxgxEvEMG++F6pzwart%2FAO0lTSA3tL48oeHclD%2FLQMdXWhgXvefpGR3QGMqwMe8cg%3D; HttpOnly; SameSite=Strict; Path=/; Expires=Wed, 08 May 2019 07:03:43 GMT
Set-Cookie: email=%2FwGLVu+6Yv5fYpSyZwRE8TIi0MlZZ6WaN+OaKusCF6pEyQjomquJmWwqSgrcHg2dcBeMBU%2Foeg%3D%3D; HttpOnly; SameSite=Strict; Path=/; Expires=Wed, 08 May 2019 07:03:43 GMT
Set-Cookie: testing=TESTETSETESET; HttpOnly
Server: Rocket
Content-Length: 56
Date: Wed, 01 May 2019 07:03:43 GMT
{ ... }
I've tried changing the HttpOnly, SameSite, Secure and domain settings, but so far nothing.
Any ideas?
Samsung internet version 9.2.00.70
Edit:
It seems like maybe it's because the cookies are being set from an Ajax query. I changed it to be a response from a normal form POST, and it seems to have worked. More digging...
Turns out it was due to my Ajax request. Once I added credentials: "same-origin" to the request, it works as expected.
your question have helped me too. I have the exactly same bug in Samsung Browser 9.2. I'm using github fetch implementation and in the docs you can see:
The default value for credentials is "same-origin".
The default for credentials wasn't always the same, though. The
following versions of browsers implemented an older version of the
fetch specification where the default was "omit":
Firefox 39-60
Chrome 42-67
Safari 10.1-11.1.2
If you target these browsers, it's advisable to always specify credentials: 'same origin'
explicitly with all fetch requests instead of relying on the default:
So it's why explicitly set credentials: "same-origin" have worked for you and for me too.
I am an Oracle Developer, we have a requirement to read the contents of a filenet documents via oracle database , but OpenSSO is enabled in our environments which is currently blocking us to read the data from filenet server.
While checking with OpenSSO guys , they confirmed that while invoking the filenet URL via browser , a session cookie gets generated in OpenSSO which plays a significant role in authentication.
But , when we tried to invoke the same filenet URL via Oracle pl/sql ( i.e database) , we could see the cookie details as below. However, we don't understand , why opensso was still not showing 'successful authentication'.
We googled the error code X-AuthErrorCode: -1 which says "In the response you're going to receive "X-autherrorcode" header, if it's value 0, then the login was successful. Also, you need to check the
iPlanetDirectoryPro cookie for admin session id".
With all these information, can someone please help us in getting the root cause of the authentication failure in OpenSSO?
HTTP response status code: 200
HTTP response reason phrase: OK
X-Powered-By: JSP/2.1
Server: Sun GlassFish Enterprise Server v2.1
Cache-Control: private
Pragma: no-cache
Expires: 0
X-DSAMEVersion: (2011-March-02 18:42)
AM_CLIENT_TYPE: genericHTML
Set-Cookie:
AMAuthCookie=AQIC5wM2LY4SfcyXSVnslvF7a5TLMa4KXz5Op9tRKzczinU.*AAJTSQACMDE.
*; Domain=.companyname.co.uk; Path=/
Set-Cookie: amlbcookie=01; Domain=.companyname.co.uk; Path=/
X-AuthErrorCode: -1
Set-Cookie: AMAuthCookie=LOGOUT; Domain=.companyname.co.uk;
Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/
Set-Cookie: JSESSIONID=286b0c94d89dffd4f602831969ae; Path=/opensso;
Secure
Content-Type: text/html;charset=UTF-8
Date: Fri, 24 Oct 2014 14:19:23 GMT
Connection: close
While downloading a Text file from filenet, we got the content as below
HTTP Status 401 -
type Status report
message
descriptionThis request requires HTTP authentication ().
Sun GlassFish Enterprise Server v2.1.1
Can someone please help me at the earliest to get a solution for this ? Is this really possible to make the authentication success via oracle database packages rather than invoking the URL via browser ? if it is possible what should be next step I need to do ?
Any help would be much appreciated.
Thanks and Regards,
Remya Sudhakaran
I am not using the SBT, but making direct REST calls with Abdera to the current version of Connections on IBM SmartCloud. REST URL in question: https://apps.na.collabserv.com/search/serviceconfigs
Observations
When testing from my laptop (using Firefox and the REST client add-on,) this works as expected. I get back an ATOM feed.
When testing from a server (on a different network,) using the same method (Firefox + REST client,) I get back HTML that is a log-in page.
In addition, I get this same result when I call the URL from a Java program on the same server.
In all cases, I am using the same credentials with basic authentication.
Update: If I log into SmartCloud first, on a separate tab in Firefox on the server, then call the URL as before, from another tab, it works. I get the ATOM feed as desired. Naturally, this is unsuitable as a solution, but I present it as additional information that could lead to an actual solution.
Update: Further testing shows that the local (laptop) log-in exhibits the same behavior as the server. A form-based log-in is required from the same browser, then subsequent REST calls work.
Update: Here is a relevant simplified code snippet:
private static Abdera ABDERA = new Abdera();
private static AbderaClient ABDERA_CLIENT = new AbderaClient(ABDERA);
...
String host = "https://apps.na.collabserv.com";
ABDERA_CLIENT.addCredentials(host, AuthScope.ANY_REALM, "basic", new UsernamePasswordCredentials("user", "password"));
...
ClientResponse response = ABDERA_CLIENT.get("https://apps.na.collabserv.com/search/serviceconfigs");
Summary
It appears that something about the originating server or the call is causing SmartCloud to respond with a log-in page. Whereas, the same call and credentials from my laptop, work as expected.
Question
Where should I start to trouble-shoot this? How can I build the client credentials to allow programmatic log-in?
Response Headers
If it helps, here are the response headers that I get back in each case.
Unsuccessful
Status Code: 200 OK
Cache-Control: no-cache
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 1850
Content-Type: text/html
Date: Tue, 08 Oct 2013 14:15:03 GMT
Pragma: no-cache
Server: WebSEAL/6.1.1.3 (Build 110428)
Set-Cookie: PD-H-SESSION-ID=4_0_IR4***masked***oRKlJI;secure; Path=/; HttpOnly BIGipServerE3A-WebSEAL-80-fe=2132806922.20480.0000;secure; path=/
Vary: Accept-Encoding
p3p: CP="NON CUR OTPi OUR NOR UNI"
Successful
Status Code: 200 OK
Cache-Control: public, max-age=86400, s-maxage=86400, no-cache=set-cookie, private, must-revalidate
Content-Encoding: gzip
Content-Language: en-US
Content-Length: 1164
Content-Type: application/atom+xml; charset=UTF-8
Date: Mon, 07 Oct 2013 17:21:12 GMT
Expires: Tue, 08 Oct 2013 17:21:12 GMT
Server: WebSphere Application Server/8.0
Vary: Accept-Encoding
p3p: CP="NON CUR OTPi OUR NOR UNI"
x-lconn-auth: true
x-powered-by: Servlet/3.0
#Grant is your login using SAML? I could see this redirect happening. also could be TFIM related... maybe you should grab the auth on a different page, store the cookies, and then try connecting to the endpoint above.
I'm using googlerequest object to retrieve notification data for a certain serial-number in sandbox environment.
POST argument (xml) I send to google:
<?xml version="1.0" encoding="UTF-8"?><notification-history-request xmlns="http://checkout.google.com/schema/2"><serial-number>631274667786221-00005-6</serial-number></notification-history-request>
Response from curl:
HTTP/1.1 500 Internal Server Error
Content-Type: application/xml; charset=UTF-8
Date: Mon, 03 Jun 2013 12:28:57 GMT
Expires: Mon, 03 Jun 2013 12:28:57 GMT
Cache-Control: private, max-age=0
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Set-Cookie: S=payments_api=P4yzgVwZyqdAb7S_BUtJXw; Expires=Mon, 03-Jun-2013 12:58:57 GMT; Path=/; Secure; HttpOnly
Server: GSE
Transfer-Encoding: chunked
<?xml version="1.0" encoding="UTF-8"?>
<error xmlns="http://checkout.google.com/schema/2" serial-number="f9338a0b-b14a-4afc-956b-5618b9741245">
<error-message>Internal error in server</error-message>
</error>
Can't answer for Google but it seems Google Checkout sandbox seems to have been shutdown / deprecated (already). This is my guess/perception as I cannot login to my Google Checkout sandbox which was at https://sandbox.gogle.com/checkout/sell for sandbox related activity like integration settings, debug console, etc.
I do see that the former sandbox Merchant center is accessible at:
https://wallet-web.sandbox.google.com/manage
So you can check sandbox orders (across different APIs) but as stated, it doesn't have the knobs/switches relevant to Google Checkout (other APIs have different "consoles" for API settings).
I don't know why (if it's early deprecation)...perhaps it's late in the game as it pertains to Google Checkout retirement to start debugging now....
See Google Checkout deprecation/retirement in November 2013 announcement and more info.
Update
Q: issue happens when I set the following options and send them via curl(): $options['shopping-cart.buyer-messages.include-gift-receipt-1'] = 1; $options['shopping-cart.buyer-messages.special-instructions-1'] = '';
You mean in the initial Checkout POST you sent to Google? If so, that instruction tells Google to offer those screens at the Google Checkout web site (not yours). I believe you shouldn't provide values for one field only - you'll have to provide all fields if you want to pre-populate from your web site.
Sorry, really tough to debug without Integration Console (which was part of the original Google Checkout console/UI in both sandbox and production) - which likely would have shown more error detail....
We have a Magento application which is issuing dual Set-Cookie's . Here are the headers:
HTTP/1.1 200 OK
Date: Wed, 18 Apr 2012 21:04:28 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.2.10
Set-Cookie: frontend=iti6c00cdm6cc79hfl1pl9pq52; expires=Wed, 18-Apr-2012 22:04:28 GMT; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: frontend=iti6c00cdm6cc79hfl1pl9pq52; expires=Wed, 18-Apr-2012 22:04:28 GMT; path=/; domain=**example.com**
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
In some circumstances, after logging in the second cookie is set to frontend=deleted . From my reading it appears that two frontend= cookies are not a "problem", this is standard Magento behaviour. From my reading of the spec, the second frontend= cookie will overwrite the first if their scope/spec is the same.
Any ideas where we can start digging in to this problem to see why the second frontend= cookie does not behave like the first?
Magento version is enterprise edition of ver. 1.9.0.0
Related Questions
Why does Magento use 2 cookies per session?
Magento Cookies Changing Prevent Frontend Login
This happens when the Session validation checks fail - the cookie will then be cleared with the "deleted" value and a expiration date in the past:
The following information will be checked by Magento for validating a session:
The client IP address that is connecting to the server
The "Via" HTTP-Header
The "X-Forwarded-For" Header
The "User-Agent" Header
If one (or more) of these informations changes during the requests for the same Session ID, the session will be Discarted, the Cookie will be cleared in the way as described and the Server will send a Redirect header to the Homepage.
You can change which Information to validate in the Magento Admin-Panel by going to System > Configuration > Web. But you should never turn off all checks since this will allow session hijacking.
Do you want to override fronten cookie... if so better try to first destroy the cookie and then reset it by using Magento method
Mage::getModel('core/cookie')->set('frontend', $session->getCustomer()->getId(), 100000*24*3600);