I know SiteMinder can add HTTP headers to the HTTP request so that backend devices (the web server, app server, etc) can have the headers for processing. But on the way out back to the client (browser), can SiteMinder add a HTTP Response Header so the client can use it?
I see a response type of WebAgent-HTTP-Header-Variable but it seems that is only accessible on the server side.
I've quick searched through some documentation and Googled, but the SiteMinder documentation is well, less than I would hope for. :)
From my recent understanding, HTTP Headers are only accessible at the server and never available on the client side unless the IIS/Web server/Application pushes them through.
Here is a link to CA's SiteMinder information that does NOT specify the above specifically:
https://wiki.ca.com/display/sm1252sp1/Default+HTTP+Headers+Used+by+the+Product
but it does say it passes it to the 'web application', which to me means only to the server.
So if you need the variable, you have to capture it at the server and send it to the client browser. In most cases this should NOT be done. Ask you company's security group for guidance here on SiteMinder headers. The company I work for created custom headers for my app, not the ones automatically sent from a canned SiteMinder installation.
Related
I want to call REST-services from my Angular-app. However, these REST-services are hosted on WLP and are part of a WAR-file developed by some company a while ago, ie. we have no source code.
I can call GET-methods without any issues from Postman, I just need to set authentication and accept headers. However, calling these GET-methods from Angular via web browsers will trigger preflight request (OPTIONS) without Authentication header prop. Seems to me that OPTIONS requests are triggered by the browsers and Angular cannot set headers for them. I confirmed OPTIONS requests need authentication by running requests via Postman with and without auth header prop.
Similar problems were discussed in other posts on stackoverflow but in such cases people had control over their server side code and could alter it to avoid authentication headers for OPTIONS request. Clearly in my case, I cannot do it.
My question is if there is a possibility to configure WLP to not ask for authentication header prop in case of OPTIONS-requests (seems to be configurable for Apache web servers and Tomcat)?
Kind regards
A.H.
Even without source, you should be able to edit web.xml and modify the security-constraints to punch a hole for OPTIONS.
Today I faced the term "cookiejar" (package net/http/cookiejar). I tried to gather some information regarding it, but got nothing intelligible came out. I know that cookie is key/value pairs that server sends to a client, eg: Set-Cookie: foo=10, browser stores it locally and then each subsequent request browser will send these cookies back to the server, eg: Cookie: foo=10.
Ok, but what about cookiejar? What is it and how does it look like?
As you described in your question, cookies are managed by browsers (HTTP clients) and they allow to store information on the clients' computers which are sent automatically by the browser on subsequent requests.
If your application acts as a client (you connect to remote HTTP servers using the net/http package), then there is no browser which would handle / manage the cookies. By this I mean storing/remembering cookies that arrive as Set-Cookie: response headers, and attaching them to subsequent outgoing requests being made to the same host/domain. Also cookies have expiration date which you would also have to check before deciding to include them in outgoing requests.
The http.Client type however allows you to set a value of type http.CookieJar, and if you do so, you will have automatic cookie management which otherwise would not exist or you would have to do it yourself. This enables you to do multiple requests with the net/http package that the server will see as part of the same session just as if they were made by a real browser, as often HTTP sessions (the session ids) are maintained using cookies.
The package net/http/cookiejar is a CookieJar implementation which you can use out of the box. Note that this implementation is in-memory only which means if you restart your application, the cookies will be lost.
So basically an HTTP cookie is a small piece of data sent from a website and stored in a user's web browser while the user is browsing that website.
Cookiejar is a Go interface of a simple cookie manager (to manage cookies from HTTP request and response headers) and an implementation of that interface.
In general it is a datastore where an application (browser or not) puts the cookies it uses during requests and responses. So it is really a jar for cookies.
I want to do place on server application which can be called by Go APP and Java app both.
for some reason ,there's a cookie authentication and oAuth mechanism ,so I want to set one Go app as Auth Micro-service for the authentication purpose.
As GRPC is built on the HTTP2 ,so The headers and cookies are on the protocol.but I did not find out how to carry on header and cookie when the rpc occurs,implemented by Go, on GitHub I only found the JAVA-Implementation for headers at :
https://github.com/grpc/grpc-java/tree/master/examples/src/main/java/io/grpc/examples/header
Can anybody give me some direction of Go implementation for this purpose?
Headers in gRPC are called "Metadata." Clients can only send "headers". Servers can send both "headers" and "trailers."
You want to:
Use the google.golang.org/grpc/metadata package and metadata.NewContext() to send metadata from the client-side.
Use grpc.SendHeader() and grpc.SetTrailer() to send metadata from the server-side.
Use the grpc.Header() and grpc.Trailer() CallOptions for receiving the Metadata on the client-side.
Use metadata.FromContext() for receiving metadata on the server-side.
Cookies support - Problem?
Original Issue/Background:
We have API based on servlet / JSON running in Openshift, the web server used in openshift is Tomcat.
We store information to httpsession and everything works fine when used directly against openshift / tomcat (POST / GET). But when we configured apigee against existing methods the session is lost. Stuff is stored correctly in the session in server side, but when second request comes from apigee into the tomcat the session is "lost"
Piece of java code to get the session is plain httpsession.getRequest(). As said this works fine when using backend directly. Is there some additional steps (cookies etc) needed to maintain the session when requests are used through apigee?
Update Findings;
With short debug an traffic monitoring the reason of the error in apigee is confirmed to be that it does not pass JSessionId to requests. This means that cookies support should be enabled somehow in the API proxy settings / Configuration.
Anyone have an idea where or if this can be resolved?
First off, cookies aren't part of a proper RESTful payload -- if you grabbed the headers you could store them with an access_token as part of the generate token policies.
That aside, you should be able to pass the cookies back to the requesting App and then let the app pass them back to the API -- my jokeindex API lets you do this.
Make sure you don't have any AssignMessage policies in the flow that are stripping out the headers accidentally -- something like this:
<Set>
<Headers />
</Set>
as that will remove ALL headers. Also, you can look at the Trace tool in Apigee to check each policy step along the way to see if you're stripping the Cookie: header from the requesting payload.
When you have your resource on address "http://yourdomain.com/somewhere/", and you redirect to that resource from apigee API, for instance by url: http://yourapi.apigee.net/v0/myresource" what you get back from your server is cookie for /somewhere/ not v0/resource/somewhere, so basically when browser gets cookie back, it does not put it into correct place and discards it. At least that was/is my case.
You should ping #bissell about this but I did find this article that might be helpful:
http://community.apigee.com/groups/learn-create-and-manage-apis/some-basic-questions-new
Also, you might be able to fix your issue by adding an "extract variable" policy to the request that captures the JSessionId and then adding an "assign message" policy to add it back to the request.
You can assign policies from API Platform>Dashboard>API Proxies>YOUR API>Develop
Hey SO, so I've got an API I'm making calls to in a browser application. Said API lives on a server that requires whitelisting and HTTP Digest Authentication.
To meet the whitelisting requirement, I'm running all API calls through a proxy, which is whitelisted. The calls are originating from an iFrame, currently populated by an index.html file.
What I need to know is how I can authenticate via HTTP Digest in the background. Most of the resources I can find online seem to involve the original HTTP Digest Authentication setup, but what I'm looking to do is automate login.
Despite the non-secretive subject matter, it is somehow critical that I keep the digest parameters obfuscated from users. Perhaps I could change the served file to index.php and then somehow set the magic headers? Even then, if the calls made via XHR, would the index.php headers authenticate the separate request?
Overall, I'm just lost, and the API developers in question are not exactly responsive, so thought I'd turn here.
It appears that in the end, this was not possible. I had to switch to building a thin back-end to route requests through.