How to connect to sub URL using java maintaining the session? - java

There are two URL, suppose URL1 and URL2. URL1 can be used only by provide the proper credentials. I have completed this part by writing the code for simple authentication. However to connect to URL2, I have to maintain the session from URL1. I cannot figure this part out. It is showing response code as Forbidden!

, I have to maintain the session from URL1.
It is not likely since on any website, the session is maintained only if the first connexion is maintainted. HTTP is stateless
When you authenticate on a website, generally, you receive a token in the HTTP response (generally in the headers). After being authenticated, for each request, you must re-send that token in your HTTP requests (generally in the headers) otherwise the server considers you as unauthenticated.
So, to solve your problem, you should analyse what the server give you in headers response when it authenticates you successfully.
If you can test your scenario with a browser which owns tools to intercept request/response content, you should easily find the token information sent in the request.

Related

How to create a custom Authenticated API request using xAgent?

I am creating a simple API database using an xAgent, Another application is requesting data by sending in a query in the request headers and I process the header and send back the requested data, so far so good.
I now need to add some sort of authentication to this request. but without using Domino authentication. if I use postman and send in a username and password as "basic authentication" that is not correct Domino sends back the following:
nHTTP: user [xxx.xxx.xxx.xxx] authentication failure using internet password
So if I send in username and password in a Basic Authentication request, Domino will try to login the user to Domino. However I do not want to do that.
I want to provide my own username and password that the request must match to get the data. (So if correct username/password is sent in I will send back the data anonymously to the user)
I am guessing that using Authenticated requests feature will somehow make it safer.
Can I set Domino to ignore the authenticated request for my application so that I can handle it in code?
or should I just let the external application send in username and password in the request header as base64?
advice needed
thanks
Thomas
Just use another header (it is YOUR Api), i.e. X-Auth and handle it by yourself.
But keep in mind that this lowers the security if you make a mistake...

Is there any Jersey client setting that would allow resending of cookies with a redirect?

I am using Jersey 2.17. I want to implement the following scenario on client side:
my Jersey client sends a request to a certain URL;
the server will return me a HTTP 301 with a Set-Cookie: abc=def header (this is given, we don't have to worry about it);
my Jersey client follows the redirect;
my Jersey client sets the abc=def cookie in the second request (to the redirect target).
Redirection works fine, so step 3 is not a concern.
What I don't know is if the cookie handling is possible, as I need it. Does anybody know for sure?
If the cookie domain is the same as the redirected URL's domain, then the cookie does not need to be sent again, so long as the client accepts and respects the first Set-Cookie.
If the domains are not the same, this sounds like a security risk: cookies are deliberately scoped to a specific domain (or set of domains) and to expose a cookie outside of that would risk leaking potentially-sensitive information. So cookies should not be re-transmitted on a redirect across domains.

Java Jersey - Rest connections through a proxy

I developed an application in java that needs to consume a set of webservices provided by a provider.
Basically I need to call a first rest webservice to connect to the system, in which I pass username and password in the body of the post rest call.
Without using proxies I can make a second rest call without passing username and password, the webservice provider recognises me.
But when I use a proxy this second call does not work any more, I get an HTTP 401 error.
Notice that the first connect call works well also with the proxy.
Is there something conceptual that I'm missing?
Anyone knows what is happening?
Thank you
If you're making only a single login request and then making follow up requests which do not supply credentials, the service you are consuming probably is using cookies to track a user session.
When you put a proxy between yourself and that service, if the proxy is not forwarding all of your HTTP header information (where the cookie is probably being exchanged with the service), then the service will no longer recognize your session and consider you unauthorized
You may need to better understand how the service is maintaining your session (is it using Set-Cookie headers that it expects you to send back?) And you need to understand if the proxy you are using is forwarding all of your headers to the service

HTTP Authorization header consistency in requests

HTTP specification says;
HTTP access authentication is described in "HTTP Authentication:
Basic and Digest Access Authentication" [43]. If a request is
authenticated and a realm specified, the same credentials SHOULD
be valid for all other requests within this realm (assuming that
the authentication scheme itself does not require otherwise, such
as credentials that vary according to a challenge value or using
synchronized clocks).
I don't really understand what this means, but here is my scenario is there anything against HTTP specs here? I use Java Rest service
Client sends username:password using HTTP Authorization header using HTTP Basic
Server sends back a token
Now client sends a custom authorization token instead of password for further requests still in the HTTP authorization header still using HTTP Basic username:token
Now this does not feel right since what I am really doing with the auth token is NOT an actual HTTP Basic authorization. Also usage of the very same header is inconsistent between requests.
But on the other hand I do not want create yet another custom header for the token exchange. Because its hard to base64 encode them with test tools when you use a custom header. And still inconsistent headers between requests.
Note: these requests refers to different endpoints
What do you advice?
If you do that, since you are using the same headers, aren't you going to need server side logic to differentiate when the login is the actual login, as opposed to your token? At the end of the day, HTTP Authorization is already a token (only a simple encoded version of the username/password string), so in all cases you are receiving a token, now you have to decode it, decide if it's one of your session tokens, or if it's a username/password, and therefore check against two sources of "good tokens".
I would advice against this, but not because you're breaking standards, it just feels convoluted.
Why do you need to change username/password to a token on the first place? Are you redirecting to an endpoint where you no longer require HTTP Basic Auth?

How to test Webservice in JDeveloper that uses Basic Authentication?

I have created a web-service that uses basic authentication in JDeveloper 11.1.1.4.
When i test my application using a client application is runs correctly so i know that the authentication mechanism has no problems.
How can i pass authentication info into the HTTP Analyzer by right clicking on Webservices and selecting Test Web Service?
I have tried to pass credentials through SOAP Headers > :WS-Security:Header like below but is not working
I have also tried to pass authentication through Credentials option like shown below
In both cases i get this error 500 HTTP Analyzer Server Error The server sent HTTP status code 401: Unauthorized: .....
How can i get through this?
Thanks
UPDATE
I also tried to pass Authentication option to Request HTTP Headers but get the error message :
Error 403--Forbidden
From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
If you're using Basic authentication, all you need is set request header Authorization. Value of this header: prefix Basic, one space, Base64 encoded string with usrname:password, so your header for Aladin:sesam open should be like this: Basic QWxhZGluOnNlc2FtIG9wZW4=.
On screenshot i see section Request HTTP headers, add Authorization header to it.
I am aware that this is an old post , but this may benefit those who run into this issue.
I am using Jdeveloper 11.1.2. I have secured the JAX-RPC web service (created by exposing PL/SQL poackage) using basic authentication. I attached the security policy: "Auth.xml" using the wizard.
I was able to test this using HTTP Analyzer. I just passed the user credentials in the SOAP Headers as shown below and it worked fine for me.(I also passed invalid creds and no creds to see if the security works as expected.)
Hope this helps !!!

Categories

Resources