We would like to use PUT, PATCH and DELETE methods when building our internal API in Domino, but I can't configure those methods. Server refusing to pass them.
When I used method PUT Domino replied to me:
Error code: 405 | Request method is not allowed by the server
After that I enabled methods via notes.ini
HTTPEnableMethods=GET,POST,PUT,DELETE,HEAD,PATCH
That seems to help a bit but now it says something about URL, but I do not really get what it means.
Error code: 405 | The HTTP method is not allowed for the specified URL
I have made tests on two different setups: with and without internet sites documents enabled in server documents.
Does anybody what I need to do to solve the problem above?
UPDATE
I just noticed a help text on Internet Site for "Methods" field.
GET, HEAD, and POST are the most commonly used methods. OPTIONS and TRACE are useful for debugging. PUT and DELETE should only be enabled if the Web site includes special CGI programs or Java applications that implement them.
Based on that it seems it is not possible to make PUT and DELETE work out of the box.
Related
I started working with the WebDAVSharp.Server library to make it work in a custom project of mine.
The amount of changes I had to do was breathtaking.
I have reached the point of making it work in an acceptable manner for my case, but I still have an issue with Office 2003 opening the files as read only.
I have fixed the non-root problem that I had, and my server responds to the PROPFIND and OPTIONS methods on all the levels of the webdav link, but Office 2003 opens the document as read-only and when trying to save it on the WebDav URL manually, it stops itself from saving the document after my PROPFIND response. And I cannot find why it does that, because I have checked almost everything. Also, newer Office versions (e.g. 2013, 2016) don't have this problem.
Here is the request from MS Word:
And here is the WebDav response:
And here are the response headers:
I am not an expert on WebDav, but it asks for all the properties of the documents and the response gives it just that. What else does it want?
Also, it never sends a LOCK method, so I doubt it is a LOCK problem.
And the request flow is like that:
The unauthorized requests are because it first sends the request without credentials and then it re-tries with credentials.
The first PROPFIND is for the containing folder/collection. I give a proper response to that, signifying it is a folder.
What is weird, is that Office 2003 never seems to issue an OPTIONS request, so I never send the MS-Author-Via header. So, this can be what causes the problem, but what can I do to force it send this request?
Any ideas or hints are welcome. I am sure there are people out there that can find the problem by simply looking at this.
UPDATE:
After seeing this, I added the Win32FileAttributes property and others from the same Microsoft namespace, but I still don't see any improvement in the behavior. This is my new PROPFIND response XML:
But I think I should approach it the other way around: Find out why after the GET method the document is in Read-Only mode.
One thing that I also fixed, is to trust my proxy certificate, which changed the request flow to this:
Servicestack Version: 3.9.71.0
Target Framework: .NET 3.5
Program background: has been in production use for over 3.5 years
Recently due to a customer security audit items were brought to our attention. All but one have been eliminated as IIS configuration changes.
The last item identified describes a situation in which the probing software accessed an endpoint without the proper authentication. This was fine and the expected result was the 403 Forbidden. The unexpected result was that the response body is displaying certain internal information of the server.
Based on quite a few articles I have searched it seams the the response body information being returned is a result of how Servicestack my be configured.
I realize this is a fairly older version of Service Stack. My preference would be to identify an IIS setting to override a forbidden response. Aside from that an option to just return a status code of 403 without the additional information. The third would be to create and use a custom 403 response object to control what is revealed.
Any guidance or help would surely be appreciated.. Thank you in advance.
ServiceStack v3 is a very old version of ServiceStack last updated in 2013. If you need to make any changes you'll need to create a custom build from its Sources
Looking at the v3 sources for how it resolves the ForbiddenHttpHandler:
ForbiddenHttpHandler = config.GetCustomErrorHttpHandler(HttpStatusCode.Forbidden);
It looks like you'll be able to override what HttpHandler is used by overriding the CustomHttpHandlers, e.g:
EndpointHostConfig.Instance.CustomHttpHandlers[HttpStatusCode.Forbidden] = MyHandler {...}
We work on a product that is a series of components that could be installed on different CMSs and provide different services. We take a CMS agnostic approach and try to use the same code in all the CMSs as much as possible (we try to avoid using CMS API as much as we can).
Some part of the code needs to work with the current URL for some redirections so we use Request.Url.ToString() that is something that has worked fine in other environments but in Kentico instead of returning the current page we always get a reference to CMSPages/PortalTemplate.aspx with a querystring parameter aliasPath that holds the real URL. In addition to that, requesting the Template page using a browser gives you a 404 error.
Example:
Real URL (this works fine on a browser):
(1) https://www.customer.com/Membership/Questionnaire?Id=7207f9f9-7354-df11-88d9-005056837252
Request.Url.ToString() (this gives you a 404 error on a browser):
(2) https://www.customer.com/CMSPages/PortalTemplate.aspx?Id=7207f9f9-7354-df11-88d9-005056837252&aliaspath=/Membership/Questionnaire
I've noticed that the 404 error is thrown explicitly by the template code when invoked directly. Please see below code from Page_Init method of PortalTemplate.aspx.cs:
var resolvedTemplatePage = URLHelper.ResolveUrl(URLHelper.PortalTemplatePage);
if (RequestContext.RawURL.StartsWithCSafe(resolvedTemplatePage, true))
{
// Deny direct access to this page
RequestHelper.Respond404();
}
base.OnInit(e);
So, if I comment the above code out my redirection works fine ((2) resolves to (1)). I know it is not an elegant solution but since I cannot / don't want to use Kentico API is the only workaround I could find.
Note that I know that using Kentico API will solve the issue since I'm sure I will find an API method that will return the actual page. I'm trying to avoid that as much as possible.
Questions: Am I breaking something? Is there a better way of achieving what I trying to accomplish? Can you think on any good reason I shouldn't do what I'm doing (security, usability, etc)?
This is kind of a very broad question so I was not able to find any useful information on Kentico docs.
I'm testing all this on Kentico v8.2.50 which is the version one of my customers currently have.
Thanks in advance.
It's not really recommended to edit the source files of Kentico, as you may start to run into issues with future upgrades and also start to see some unexpected behaviour.
If you want to get the original URL sent to the server before Kentico's routing has done its work, you can use Page.Request.RawUrl. Using your above example, RawUrl would return a value of /Membership/Questionnaire?Id=7207f9f9-7354-df11-88d9-005056837252, whereas Url will return a Uri with a value of https://www.customer.com/CMSPages/PortalTemplate.aspx?Id=7207f9f9-7354-df11-88d9-005056837252&aliaspath=/Membership/Questionnaire (as you stated).
This should avoid needing to use the Kentico API and also avoid having to change a file that pretty much every request goes through when using the portal engine.
If you need to get the full URL to redirect to, you can use something like this:
var redirectUrl = Request.Url.GetLeftPart(UriPartial.Authority) + Request.RawUrl;
I'm working on an AngularJS app that uses Domino as a backend. Since I want more customization options than Domino Access Services (DAS) gives me, my next choice was the REST Service from the Extension Library.
The app is running on a separate domain from Domino, so I need to add CORS headers to make that scenario work. With CORS, the browser (for some requests) first makes a preflight HTTP OPTIONS request to the server to check what methods are allowed (more on CORS here: http://www.html5rocks.com/en/tutorials/cors/).
The problem I now run into is that Domino throws a Method Not Allowed error (response code 405) on that OPTIONS request. I already added it to the list of allowed methods in my internet site document (although I'm not sure if the REST service will honor that at all). The request comes through fine with DAS.
Looking at the source code of the RestDocumentJsonService in the Extension Library it seems that the OPTIONS method isn't supported at all.
Any thoughts on how to make this work? Or for a workaround? I know that I can write my own servlet or install a proxy in front of Domino, but I don't want to go that route (yet ;-)
If you are trying to use Authenticated CORS you will need minimum four headers to work
Access-Control-Allow-Credentials: true
access-control-allow-header: X-Requested-With, Origin, Accept, Accept-Version, Content-Type
access-control-allow-method: OPTIONS, GET, PUT, POST, DELETE, PATCH
access-control-allow-origin: http://yourOtherDomain.com
Unfortunately you can only add 3 headers through the Web Site documents
You cannot add anything through a Phase Listener because the ExtLib Rest Services do not go through the XSP Phases
You can use a proxy such as nginx or in my case I used IHS
http://xomino.com/2014/04/20/adding-custom-http-headers-to-domino-r9-using-ibm-http-server-ihs/
Or you can just roll your own REST service and add whatever headers you want
Mark, just a quick comment. I am not sure if this would work for you.
But what I do in a current project is to put the Angular app in the WebContent folder of the NSF. This serves several purposes - one of them being ease of deployment with the right version of the backend code in the same NSF. I have set the database up for source control and edit the Angular part directly in the on-disk project of the NSF and just sync them when I need to run it. As a side effect this setup will also solve any CORS issues as client side code is launched from the same domain as my REST service is called from ;-)
/John
I am developing an ASP.NET Web API application which responds to the clients with a custom datetime http header. While I have read several articles describing how to remove response headers from ASP.NET/IIS, this one always seem to be resilient, i can't get rid of it. It seems to be placed in the response pipeline somewhere out of the programmer's/administrator's control, at the very end.
I know it may be a bad practice not to include the "Date" header in the response but, as i mentioned, the custom datetime header (which is in ticks instead of a string representation) makes the default one redundant; furthermore, this is a private API, so i know exactly who and how uses it.
Is it thus possible in any way to remove this header in IIS (v7+) for a specific site (or directly from the Web API application)?
Edit:
I tried (without success) the following techniques:
Creating a custom handler to remove the header right from the Web API project
Registering a custom IHttpModule
Explicit removal of headers in web.config in <httpProtocol><customHeaders> section
Remove HTTP response headers in IIS Manager
Header removal code in protected void Application_PreSendRequestHeaders(object sender, EventArgs e) method in Global.asax.cs
According to HTTP Spec, Date header is mandatory, except for these conditions which I dont think apply to your case:
Origin servers MUST include a Date header field in all responses, except in these cases:
1. If the response status code is 100 (Continue) or 101 (Switching
Protocols), the response MAY include a Date header field, at
the server's option.
2. If the response status code conveys a server error, e.g. 500
(Internal Server Error) or 503 (Service Unavailable), and it is
inconvenient or impossible to generate a valid Date.
3. If the server does not have a clock that can provide a
reasonable approximation of the current time, its responses
MUST NOT include a Date header field. In this case, the rules
in section 14.18.1 MUST be followed.
This is not going to be possible from within the actual WebApi/Mvc pipeline, so options like action filters and delegating handlers are out.
Instead you will probably need to implement a custom IHttpModule and register it inside IIS. There is an article here you should read and follow. The approach is very simple and easy to adapt.
Just replace the set in that example with:
HttpContext.Current.Response.Headers.Remove("Date");