That's an issue with the SSL certificate on the server. It's the kind of error you'd see if the domains on the SSL certificate don't match the domain being used to access the website. SSL certificates are a little out of my areas of expertise, so I'm not sure how you determine what you need to do to fix that.

If this is on a Windows machine, IIS will return a 404.8 error when its "hidden segment" request filtering blocks something.

Here's the documentation on it.

Yes, security settings can get down to a columnar level. Also, if what you're querying is a view rather than a table, or if the ID column is defined to be something other than ID, that column just might not exist.

Also for clarification, when you use the select *, are you getting an Id column in the resulting data?

I haven't touched PHP in a bit, but are you binding your columns? I seem to remember PHP things getting a little finicky about making sure you do that before you fetch if you were specifying columns in the query, but not if you were doing a select *.

I didn't check the credentials because this all takes place after the user has already been through the authentication process. If they aren't valid, they wouldn't get this far anyway. My approach is dealing with just the authorization, not the authentication. I still use $SYSTEM.Security.Check to see if the process has the right permissions.

As you said, it comes down to personal preference. One of my preferences is not messing with the authentication processes if I don't have to. That way I don't have to account for all of the different authentication options, and they could all still be used.

I was actually pondering this question myself for an article I'm working on. I ended up in a very different place than you did, though. I created an Abstract class that extends %CSP.REST and overrides the XData schema, the DispatchMap method, and the DispatchRequest method. If I extend this class - which I've called REST.Resourceful - I can include a resource in the URL map as a resource:permission pair. For example:

<Route Url="/securetest" Method="GET" Call="securetest" Resource="MyResource:U" />

Will only allow you to access the /securetest endpoint if the user has Use permission on the resource "MyResource". If you don't, you get a 401 error. If I leave out the Resource attribute on that node, it doesn't check for any additional resources.

Source code is below. If you search the text for my initials, DLH, you'll see comments where I've made changes in the method, plus I added the attribute "Resource" to the XData schema.

What indices are defined for your data, and have you tried rebuilding them?

I don't typically use Ensemble for my REST services, but I do see a couple of things.

First, in the documentation you linked to, pOutput is a %DynamicObject, not a %RegisteredObject. %RegisteredObject does not have a %ToJSON() method.

Second, in your PostMessage method, the line "return pResponse" shouldn't be there.

The argument for $LISTGET has to be a list, so it would have to be $LISTGET(LIST(a)).

Where you have your query defined, does it work if you change the definition to include the SELECTMODE as RUNTIME?

Query GetAddressQuery() As %SQLQuery(ROWSPEC = "Address",SELECTMODE = "RUNTIME") [ SqlProc ]

What browsers are you using to do this? Many have restricted the use of window.close to only work on windows that were also opened by javascript using window.open.

Do so at your own risk, but if you use _PUBLIC as the role/user argument, then all users will have the granted permissions as soon as they are created.

Try:

&js<zenPage.CloseAndRefresh();>

At the end of your %OnSubmit method.

As for telling whether it's a production or test system, you might want to consider $SYSTEM.Version.SystemMode(). Calling that function with no argument will return the current system mode, which can be DEVELOPMENT, LIVE, TEST, or FAILOVER. It's usually set in the System Management Portal, but you can also call that function passing any of those strings are an argument to set it programmatically.

Assuming that's a typo and the last one is supposed to be Class BZ.Test3, this is all correct and as expected. Since it extends Test2, Test3's onloadHandler function is identical to Test2's onloadHandler, which runs its superclass's onloadHandler and prints test2. Since its superclass is Test2, it's superclass's onloadHandler is also running its onloadHandler, then printing test2. Since Test2's superclass is Test1, Test2 is running its superclass's onloadHandler, printing test1.

Remember, removing the onloadHandler method from Test3 doesn't mean that it doesn't have an onloadHandler; it just means its onloadHandler is the same as the one in its superclass, Test2.

Have you checked the timeout on the web application?

See this FAQ and look for the question "I closed my CSP session, but Caché still reports that I am using a license. Why?" I don't know much about your specific application, but that may be what you're running into. CSP sessions have a grace period that, frankly, doesn't make much sense at all. That FAQ explains how long the CSP session grace period lasts, and the question after that is about how to set the timeout for your web applications. Doing so appropriately will minimize the grace period.

FYI, the reason this is so difficult is because an XLSX file is actually a ZIP archive with a bunch of XML files in it. You'd actually have to save the file as a .ZIP, extract it, navigate to the XML files for the worksheets (on the current version, that's inside the archive in \xl\worksheets, but that's changed between versions if I remember correctly) then parse the data out of the XML file and write it to your CSV file. That's why there are all these third-party tools people are recommending to handle this issue.

What was the query you were trying to run? This looks like an issue with the way the query was written.

This, or if SecondMethod returns a value of some sort, you'd want to:

Method "this_MainMethod"()
{
    set somevalue = ..SecondMethod()
}

Method SecondMethod()
{
    // ...
}