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
Related
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
In our company the web app that we are testing uses the active directory roles assigned to the user for accessing the website.
Edit:
Important information that I forgot to mention is that, while accessing the website I am not prompted for the username and password. The website is only displayed if I have the correct Active Directory role assigned to my user profile.
For Example,
Opening IE as myself - able to access the website.
Opening IE as a service account (with required Active Directory roles) - able to access the website.
Opening IE as a different user outside my project - not able to access the website.
I have tried (skeptically, desperate to get it working) Basic/ Kerberos Authorization in the HTTP Authorization Manager and even running JMeter as that service account still no luck. I keep getting the below
Thread Name: Users 1-1
Sample Start: 2017-04-26 17:08:18 CDT
Load time: 83
Connect Time: 13
Latency: 83
Size in bytes: 438
Sent bytes:136
Headers size in bytes: 243
Body size in bytes: 195
Sample Count: 1
Error Count: 1
Data type ("text"|"bin"|""): text
Response code: 401
Response message: Unauthorized
Response headers:
HTTP/1.1 401 Unauthorized
Server: nginx/1.10.1
Date: Wed, 26 Apr 2017 22:08:18 GMT
Content-Type: text/html
Content-Length: 195
Connection: keep-alive
WWW-Authenticate: Negotiate
X-Frame-Options: deny
X-Content-Type-Options: nosniff
HTTPSampleResult fields:
ContentType: text/html
DataEncoding: null
I am just trying to find out if any one here has got the JMeter working in a similar scenario/ if any one can point me in the right direction to overcome this hurdle.
Thanks all for your help in advance.
You need to identify the exact implementation of the authentication in your application.
Given you receive WWW-Authenticate: Negotiate - this is definitely not Basic HTTP Auth.
Negotiate may stand either for NTLM or for Kerberos (or in some cases for both, i.e. if Kerberos is not successful it will fall back to NTLM) and JMeter needs to be configured differently for these schemes.
For example for NTLM you need to provide only credentials and domain in the HTTP Authorization Manager and for Kerberos you need to populate Realm and set your Kerberos settings (KDC and login config) under jaas.conf and krb5.conf files
See Windows Authentication with Apache JMeter article for more information and example configurations.
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);