Is there a standard way of addig HSTS header to embedded jetty Servlet? - jetty

I have a custom Servlet implementation that extends HttpServlet. Is there a standard way to add the HSTS header to the response?
The only way I found is adding
response.addHeader("Strict-Transport-Security", "max-age=31536000; includeSubDomains")
But then I need to do the same for all of the methods. Is there a simpler way?
Thanks for your help!
Edit: I use an embedded jetty server
Edit2: Apparently it looks like the HeaderFilter class can be used to do this, and the add the filter to the context

You have a few options.
A traditional Servlet Filter.
Be aware of DispatcherType behaviors, and what do you want to do if anything when the response is reset, or you are in a flow that isn't DispatcherType.REQUEST (eg: async, error, include, forward, etc)
Override the HttpServlet.service() method to add the header and then delegate to the normal service flow.
Create a new RewriteHandler Rule to do that for you.
Create a new Jetty Handler that adds the header and then proceeds through the handler chain to your web app (at a later point in the handler chain)
Create a HttpConfiguration.Customizer implementation to do that for you once the request has been parsed, and before it is dispatched to your web application.
Create an HttpChannel.Listener that adds the headers to the response on onResponseBegin() events.

Related

Intercept function call

I have built a "sidecar" to my micro services, to perform common monitoring and logging services.
So, i have the sidecar library that basically works by the "template method" pattern and I have a ring middleware that wrapps the calls to my services through the sidecar and it works... But i would like to remove the dependency on ring.
So, my question:
Is there a way to intercept the calls from ring to my API-functions and wrapp it without adding knowledge to neither ring or my API. Simply put, intercept calls to a random named function and replace it with my own.
I believe you can use https://github.com/technomancy/robert-hooke to do this

In QtWebkit, how does a webpage's QNetworkAccessManager::createRequest() get invoked?

I'm building a Browser application using the QtWebkit and QtNetwork modules.
Let's say that it's a requirement that each webpage only be able to access resources from only a specific folder, set aside specifically for it. In this scenario, each webpage would have some kind of ID to identify it which could be used to verify that it's accessing the correct folder.
The problem is that it's not clear how exactly the createRequest() method gets invoked. If it's a signal that's emitted or something then I would be able to intercept it and add a few parameters indicating webpage ID.
As such now the only option open to me is to create a separate QNetworkAccessManager for each QWebPage and overload the createRequest() function whereas I would really like to be able to share the QNetworkAccessManager across QWebPages.
Alternate solutions would be appreciated but generally I'm also really confused about how the createRequest() method is reached.
Reference :
QNetworkAccessManager::createRequest
It's not a big deal to have a separate access manager for each web page. You don't have any measurements to show it to be a problem, so in a true Don Quixote fashion, you're fighting windmills and imaginary enemies :)
The createRequest virtual method is called by the various non-virtual request methods: get, post and put. It's a good example of the non virtual interface (NVI) pattern.

How do you decouple a web service that requires an authheader on every call?

I have a service reference to a .NET 2.0 web service. I have a reference to this service in my repository and I want to move to Ninject. I've been using DI for some time now, but haven't tried it with a web service like this.
So, in my code, the repository constructor creates two objects: the client proxy for the service, and an AuthHeader object that is the first parameter of every method in the proxy.
The AuthHeader is where I'm having friction. Because the concrete type is required as the first parameter on every call in the proxy, I believe I need to take a dependency on AuthHeader in my repository. Is this true?
I extracted an interface for AuthHeader from my reference.cs. I wanted to move to the following for my repository constructor:
[Inject]
public PackageRepository(IWebService service, IAuthHeader authHeader)
{
_service = service;
_authHeader = authHeader;
}
...but then I can't make calls to my service proxy like
_service.MakeSomeCall(_authheader, "some value").
...because because MakeSomeCall is expecting an AuthHeader, not an IAuthHeader.
Am I square-pegging a round hole here? Is this just an area where there isn't a natural fit (because of web service "awesomeness")? Am I missing an approach?
It's difficult to understand exactly what the question is here, but some general advice might be relevant to this situation:
Dependency injection does not mean that everything has to be an interface. I'm not sure why you would try to extract an interface from a web service proxy generated from WSDL; the types in the WSDL are contracts which you must follow. This is especially silly if the IAuthHeader doesn't have any behaviour (it doesn't seem to) and you'll never have alternate implementations.
The reason why this looks all wrong is because it is wrong; this web service is poorly-designed. Information that's common to all messages (like an authentication token) should never go in the body where it translates to a method parameter; instead it should go in the message header, wherethe ironically-named AuthHeader clearly isn't. Headers can be intercepted by the proxy and inspected prior to executing any operation, either on the client or service side. In WCF that's part of the behavior (generally ClientCredentials for authentication) and in legacy WSE it's done as an extension. Although it's theoretically possible to do this with information in the message body, it's far more difficult to pull off reliably.
In any event, what's really important here isn't so much what your repository depends on but where that dependency comes from. If your AuthHeader is injected by the kernel as a dependency then you're still getting all the benefits of DI - in particular the ability to have this all registered in one place or substitute a different implementation (i.e. a derived class).
So design issues aside, I don't think you have a real problem in your DI implementation. If the class needs to take an AuthHeader then inject an AuthHeader. Don't worry about the exact syntax and type, as long as it takes that dependency as a constructor argument or property.

How does Delphi web-services work ? ( Adding method in runtime ?? )

I've created web-service in Delphi XE using WSDL importer.
Delphi generated for me module ITransmitter1.pas with
ITransmitter interface and GetITransmitter function.
To use webservice i use:
var Transmitter: ITransmitter;
begin
Transmitter := GetITransmitter(True, '', nil);
Transmitter.Transmit(Memo1.Text, OutXML);
end;
But i cant see anywhere body of method Transmit ...
In ITransmitter.pas i see:
InvRegistry.RegisterInterface(TypeInfo(ITransmitter), 'urn:TransmitterIntf-ITransmitter', 'utf-8');
InvRegistry.RegisterDefaultSOAPAction(TypeInfo(ITransmitter), 'urn:TransmitterIntf-ITransmitter#Transmit');
If i comment this lines i get "interface not supported" error.
As i see here delphi is adding method in RunTime !
How does it work ? Can i add method in runtime to my own class ?
If you created a web service client with the WSDL importer, the generated client code will invoke a method on the server. So in fact, the method 'body' (code) is on the web service server.
Delphi generates a Soap request based on the WSDL, and behind the scenes RTTI (introspection) is used to generate parameters etc. of the web service call as XML. This XML is sent to the server, which executes the method implementation and sends back a Soap response.
Things are opposite if you create the web service server, in this case the Delphi application of course needs to implement all method bodies.
You're in fact calling a method defined in a Interface, which in turn inherits from IInvokable, declared in System.pas.
If you check your source code you'll note that no local object in your project implements the IInvokable interface you're calling, that's because that method is remotely executed in the server.
Before that occurs, there's some pascal code used to create a proper SOAP request to the server, send it and then wait and interpret the server response, consider this implementation details. If you're interested in know a bit more how this works, enable the "use debug .dcus" compiler option, so you can debug inside the VCL/RTL.
Then, as usual, use the StepInto (F7) command to ask the debugger to execute the Transmit method step by step... after some assembler in the TRIO.GenericStub method you'll get to the TRIO.Generic method where the packet is prepared and sent.
For a btSOAP binding I'm using to write this response, the relevant part starts at line 943 in the Rio.pas unit:
try
FWebNode.Execute(Req, Resp);
finally
{ Clear Outbound headers }
FHeadersOutBound.Clear;
end;
THTTPReqResp.Execute then uses wininet.dll functions to perform the connection, send and receive of information with the server using.
There are some levels you can go deep with this... how far you want to go will depend on your interests and the great amount of details are far beyond the scope of my answer here... feel free to post more questions with specific tings you're interested in.
I'm not sure about, but details can change between Delphi versions... I'm using Delphi XE right now.

Logging for multi=threaded server component

I have a multi-threaded sever application that I'm writing in C++ and I need to implement a good and fairly efficient logging system. By efficient I mean that whatever amount of logging is configured, the application shouldn't ever come to a grinding halt. So preferably there is some thread that is dedicated to writing it's log files.
I want to log each request that the server component handles in it's own file, having a rotation system that removes files older then some threshold. A request is handled by 2 threads, one that does some conversion work and the a worker-thread that is part of thread pool (BOOST threadpool) that does all the other actions (database gets, calculations, etc). So the logging need be threadsafe and I have to be able to configure it for levels and let each Logger class instance (my own logger that implements some library) accept a new file name. So that each new Logger instance is created for a specific request.
My ultimate question is: Which logging library allows me to have a new Log file for each request and allows me to configure log levels? (IE: error, warning, critical, etc)
Or should I implement everything myself? (no logging is not an option)
I have looked at Boost::Logging v2 and since the main logger object, that holds all state (levels, files) is global, I cannot change the files for each request.
I have looked at templog.org and this I can't even get to compile. No matter what I include or which references I set, it can never find the templog namespace or any of its classes.
Have a look at Apache log4cxx. It a great logging library !