I was using geoserver api to create a new user for my application, after I upgraded my geoserver to 2.18.2 the same code doesn't work any more.
until now I used this route which was working absolutely fine:
http://geoserver:8080/geoserver/geofence/rest/usergroup/service/jdbc_userservice/users
If i still use this route, I get this error:
Description The origin server did not find a current representation for the target resource or is not willing to disclose that one exists.
Therefore I tried this route which I found in their api docs:
localhost:8080/geoserver/rest/security/usergroup/users
but I get this error:
Type Status Report
Message Forbidden
Description The server understood the request but refuses to authorize it.
any hint or docs about this issue will be appreciated.
I am working with Azure Mobile Services API, my API on the local host running well. I have checked with the help of Swagger UI. but when I publish my API to azure then after that by accessing the API with Swagger I got this error.
500 : {"Message":"An error has occurred."} http://xxxxxxxxxxx.azurewebsites.net/swagger/docs/v1
Now if I type this route http://xxxxxxxxxxx.azurewebsites.net/tables/doctor?ZUMO-API-VERSION=2.0.0
to any table then I got the result,
why not with swagger?
help me to get on the right path.
Please make sure your XML file is available on the same location as you have defined in the swagger UI properties on Azure.
I would highly recommend to generate your swagger xml file
Steps :
Right click on webapi project
Properties => build tab
Output section - in different folder other than bin.
For example : App_Start\\{ProjectName}.xml
I'm trying to make a GET request from an iPhone app(built on Worklight), to a remote worklight adapter on a remote server.
I have generated the authorization request header using the following
http://remote-url:port/project/authorization/v1/testtoken
However, I keep getting the following cross domain error:
XMLHttpRequest cannot load https://remote-url/project/adapters/call/mq/getAccounts/22. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://myapp-url:port' is therefore not allowed access.
But, when I try do the same GET request using an API tool like Postman, I receive the results no issues on my browser.
First - testtoken is only available from the MobileFirst Studio development environment... you need to take this into consideration.
Second, you're likely using Chrome and Crome disallows CORS by default. Change your browser settings and/or try in a different browser.
2 simple questions :
Do all http requests make thru http adapter do go thru the worklight server first?
If so then does it mean even a http adapter request to a public web site say a request to yahoo site for a stock price would also go thru worklight server first then next to the yahoo web site? If so then how do I make a http request without going thru the worklight server? I just want to go straight to yahoo web site without the "intermediate" server (i.e. workligth server)
1) Do all http requests make thru http adapter do go thru the
worklight server first?
Yes. Worklight Adapters work by executing JavaScript on the Worklight Server using Mozilla Rhino. You can read more about Adapters in the IBM Worklight Getting Started Modules. Look at Modules 5 and 6 for Adapter specific details. There are also code samples you can try next. The API documentation is in IBM InfoCenter. There is also a Developer Works article that talks about adapters that you may find helpful.
2) If so then does it mean even a http adapter request to a public web
site say a request to yahoo site for a stock price would also go thru
worklight server first then next to the yahoo web site?
Yes.
I just want to go straight to yahoo web site without the
"intermediate" server (i.e. workligth server)
IBM Worklight ships with jQuery, you can use the ajax method. Here's an example:
WLJQ.ajax( "http://finance.yahoo.com/d/quotes.csv?s=DOW+MSFT+AAPL+GOOG&f=snl1" )
.done(function (data) {
console.log(data);
});
Note that WLJQ is the namespace for the version of jQuery that Worklight ships. You can use jQuery or $ by doing: var $ = WLJQ; or var jQuery = WLJQ;.
You should get something like this back:
"DOW","Dow Chemical Comp",30.89
"MSFT","Microsoft Corpora",27.37
"AAPL","Apple Inc.",448.97
"GOOG","Google Inc.",790.13
If you use the adapter API on the client side then your request with go through the Worklight server. You can still make AJAX requests from the client side and skip the server. Essentially you'd be making server requests in the same way you would in Cordova, which means using a whitelist to allow your requests to access third party servers.
Of course You can access it directly without calling any adapter functions using simple jquery ajax calls.
$.ajax({
url: url,
data: data,
success: success,
dataType: dataType
});
or
$.get(url, function() {
alert( "success" );
})
.done(function() {
alert( "second success" );
})
.fail(function() {
alert( "error" );
})
.always(function() {
alert( "finished" );
});
Do all http requests make thru http adapter do go thru the worklight
server first?
Absolutely not, it is entirely up to you. If you are using HTTP Adapters, then the HTTP request would be initiated from the Worklight Server and it would serve you back the response.
If so then does it mean even a http adapter request to a public web
site say a request to yahoo site for a stock price would also go thru
worklight server first then next to the yahoo web site? If so then how
do I make a http request without going thru the worklight server? I
just want to go straight to yahoo web site without the "intermediate"
server (i.e. workligth server)
If you are using a HTTP Adapter, then it would go through Worklight Server as per the first answer.
If you do not want the intermediate server, then you can use the conventional means of doing the HTTP request as you would do otherwise either through the Javascript /Ajax layer or natively (Android/iOS/Windows..)
Adapters are useful when it comes to security which Worklight uses to make sure that the request is initiated from the registered device - the authentication is done by exchanging device tokens etc.
I think you are missing an important point about the adapter architecture in WL. The adapter lives in the server, so by definition, any request you make with it will "go thru" the server. However, the information is not going through your WAS (or Tomcat) server.
Is there a reason you don't want to use the adapter? I would recommend using it since it makes it easier to pull down data, whether from a RESTful http call or database query.
If you did want to get around the adapter, there are issues with cross-domain authorization. I don't have much experience in this area, but you may be able to get around it using something like jQuery.ajax().
Whenever I try to call Magento's rest resources via PHP, I get an HTTP 500 Internal Server Error. My link is, in accordance to Magento's REST API, http://mymagento.com/api/rest/products.
Everything is set up properly and whenever I try to access it via the browser, the response is a page with the XML data I want. Same thing goes for the RESTClient plugin for Firefox.
I also get the internal server error whenever I try to do an authorised request as a customer.
Does anyone know why this is happening? I ran out of ideas an hour ago or so.
If you just got that problem (only) then,
500 errors in the HTTP cycle
Any client (e.g. your Web browser or our CheckUpDown robot) goes through the following cycle when it communicates with the Web server:
Obtain an IP address from the IP name of the site (the site URL
without the leading 'http://'). This lookup (conversion of IP name to
IP address) is provided by domain name servers (DNSs).
Open an IP socket connection to that IP address.
Write an HTTP data stream through that socket.
Receive an HTTP data stream back from the Web server in response.
This data stream contains status codes whose values are determined by
the HTTP protocol. Parse this data stream for status codes and other
useful information.
This error occurs in the final step above when the client receives an HTTP status code that it recognises as '500'. (Last updated: March 2012).
Fixing 500 errors - general
This error can only be resolved by fixes to the Web server software. It is not a client-side problem. It is up to the operators of the Web server site to locate and analyse the logs which should give further information about the error.