I have a JBOSS server that allows another server to make API calls. However, I would like to limit to that particular server to access only, how can I do so using digital certificate?
please advise
Hello ~ for EAP 7:
It seems you would like to restrict the connections for a specific application.
This can be done configuring ip-access-control in your applications WEB-INF/undertow-handlers.conf:
ip-access-control(default-allow=false, acl={'127.0.0.1 allow', '127.0.0.2 allow'})
Otherwise, if you do not want to change the app side, you can create an expression filter directly on Undertow:
expression-filter name="ip-access-filter" expression="ip-access-control(default-allow=false, acl={'127.0.0.1 allow', '127.0.0.2 allow'})"/> ~~~
Related
I want to create a Power Systems Virtual server in IBM cloud. To create the server we need "cloud_instance_id" and "Power Systems Virtual Server instance ID" as a part of the API call.
I am unable to get the cloud_instance_id,Power Systems Virtual Server instance ID to proceed further on this. Please help me with the requested information.
The API call I have used is as in the below document.
https://cloud.ibm.com/apidocs/power-cloud#create-a-new-power-vm-instance
https://cloud.ibm.com/apidocs/power-cloud#authentication
https://cloud.ibm.com/apidocs/resource-controller#create-provision-a-new-resource-instance
I think you want to use this API to create the instance first.
am checked that link "https://cloud.ibm.com/apidocs/resource-controller#create-provision-a-new-resource-instance" working fine to create a service. but need to launch Power Systems Virtual Server through Rest Api
i refer this link "https://cloud.ibm.com/apidocs/power-cloud#create-a-new-power-vm-instance"
But responce is getting missing bearer token or crn
Rest URL GET- https://us-south.power-iaas.cloud.ibm.com/pcloud/v1/cloud-instances/f65a...ffc58/pvm-instances
Headers
Authorization:Bearer eyJra...
Bluemix-Instance:crn:v1:bluemix:public:power-iaas:us-east:a/516...2d:f65acd2c-7..58::
Content-Type :application/vnd.ibm.collection+json
Error
"code":500,"message":"missing bearer token or crn"..
So the ibmcloud cli [plugin need installed with this one updated to latest:
power-iaas 0.3.0
Then I was able to get the requested information:
ibmcloud pi service-list
Listing services under account *********** user *********
ID
crn:v1:bluemix:public:power-iaas:us-south:a/9efe07ec3679df7e2b3bbe1de55554be:58495336-666b-4445-a1fd-986499fa30be:: Power Systems Virtual Server-h1
crn:v1:bluemix:public:power-iaas:us-south:a/9efe07ec3679df7e2b3bbe1de6a554be:a74d57dd-bffg-4ca3-b564-6649fcb10aee:: Power Systems Virtual Server-ocp-cp4d
They names have been changed above to protect the innocent.
I am working on a java utility, deployed with the application on the same server.
Use case: Utility should run through a script file. I should be able to manage weblogic server to change these parameters on active server:
tuning.low parameters:
jta-timeout=xx
xa-timeout=xx
inactive-connection-timeout=xx
intial-db-pool=xx
min-db-connection-pool=xx
max-db-connection-pool=xx
db-thread-pool=xx
ui-thread-pool=xx
audit-thread-pool=x
jms-buffer-size=xxx
jms-buffer-count=xxxx
!--Domain Env setup--
oim-xmx=xxxx
oim-xms=xxxx
One option is to use WLST embedded. Others are to use rest services provided by weblogic or using JMX. Can you help me to choose. Which would be the preferred way of doing this.
I am trying show end users maintainence window such as "we are down please try later" and disable the application but my problem is what if my worklight server itself is down and not reachable and i cannot use the feature provided by worklight console,
Is there a way i make my app talk to a different server which returns back the below json data when a app is disabled , can i simulate this behaviour is this possible.
json recieved on access disabled in worklight :-
/*-secure-
{"WL-Authentication-Failure":{"wl_remoteDisableRealm":{"message”:”We are down, Please try again soon","downloadLink":null,"messageType":"BLOCK"}}}*/
I have some conceptual problems with this question.
Typically a production environment (simplified) would not consist of a single server serving your end-users... meaning, there would be a cluster of nodes, each node being a Worklight Server, and this cluster would be behind a load balancer that would direct the incoming requests. And so in a situation where a node is down for maintenance like in your scenario there would still be more servers able to serve - there would be no down time.
And thus at this point your suggestion to simulate a Remote Disable by sending it from another(?) Worklight Server seems not so much the correct path to take (it may even be simply wrong). Have you had this second Worklight Server, why wouldn't it just serve the apps business like usual? See again my first paragraph about clustering.
Now lets assume there is still a downtime, that affects all servers. The application's client logic should be able to handle failed connections to the Worklight Server. In such a case you should handle this in the WL.Client.connect()'s onFailure callback function to display a WL.SimpleDialog that looks just like a Remote Disable's dialog... or perhaps via the initOption.js's onConnectionFailure callback.
Bottom line: you cannot simulate the JSON that is sent back for the wl_RemoteDisable realm; it is part of a larger security mechanism.
Additionally though, perhaps a way to better handle maintenance mode on your server is to have the HTTP server return a specific HTTP status code, check for this code and display a proper message based on the returned HTTP status code.
To check for this code in a simple example:
Note: the getStatus method is available starting MobileFirst Platform Foundation 7.0 (formerly "Worklight").
function wlCommonInit(){
WL.Client.connect({onSuccess:success, onFailure:failure});
}
function success(response) {
// ...
}
function failure(response) {
if (response.getStatus() == "503") {
// site is down for maintenance - display a proper message.
} else if ...
}
There are scripts that build the admin server, then create clusters, managed servers, machines etc and when this domain is built, it is seen that an additional phantom server osb_server1 with port 8011, is getting built that isn't attached to any cluster or any machine.
This is built when the wlsb.jar was being referenced during one of the scripts.
Once after the admin server is up and running and we have other managed servers as well, Was trying to remove osb_server1 and this error creeps up
weblogic.management.configuration.AppDeploymentMBeanImpl.isCacheInAppDirectorySet()
Errors must be corrected before processding
There are like 120 default deployments on OSB that are targeted to osb_server1, was trying to retarget them to another server, but that is also throwing an error ...
Any ideas ???
That's due to the weird behaviour/bug of the standard osb template. There is a discussion here. http://theheat.dk/blog/?p=1255.
I didnt follow the steps given by Oracle(as in the URL). What I did was,
I keep the default osb_server1, and make it part of the cluster during the domain creation(ie, it's the first server). Once the domain is created, I re-set the osb_server1 to the desired value. That way the singleton services will still be deployed to the 1st server and others to cluster. Using WLST:
readDomain(domain_name)
cd('/Servers/osb_server1')
set('ListenPort', osb1_listen_port)
set('Name', osb1_name)
cd('/Servers/' + osb1_name + '/ServerDiagnosticConfig/osb_server1')
set('Name', osb1_name)
updateDomain()
closeDomain()
Worklight 5.0.6.1
We are having a specific requirement from our client about using a PCI Appliance from Intel (http://info.intel.com/rs/intel/images/Intel_Expressway_Tokenization_Broker.pdf) to avoid a PCI Audit for the application and server.
Therefore, the Adapter calls that have something to do with payment data would need to go through this hardware appliance before hitting the worklight server. All other adapter calls should go to the worklight server directly (to not overload the appliance).
The idea is to have two different URLs but the same worklight server in the background. It is assumed that the calls through the appliance will be transparent for the worklight server, so worklight functionality should not be impacted.
My questions around this would be:
a Worklight best-practice for having two different URLs for the same worklight server and alternating those URLs from the client for Adapter invocations (only; not direct update or anything else, since we assume this is executed native)?
is it possible to dynamically overwrite the worklight server URL that is used for an adapter invocation through JavaScript code in the client code? e.g. overwrite a specific JS function that gets/returns the worklight URL from somewhere before the WL.Client AJAX adapter invocation?
We are also looking into having a load-balancer switch the route based on a regex of the AdapterName that is being invoked or so. But it is not sure right now if that is possible and what the performance impact is.
Though possible, this is not something supported by WL. You will not be able to get help from support in case something goes wrong (and it will). You have to keep in mind that all server cookies (e.g. session id) are per domain. Therefore when you're dynamically changing server URL you will loose them. Therefore WL server will treat your request as a new session, unrelated to an old (existing) one. This is not something specific to WL, this is how HTTP works.
WL keeps server URLs in two global properties - WL.AppProp.WORKLIGHT_ROOT_URL and WL.AppProp.APP_SERVICES_URL. You can override them thus changing server URLs.
First one is used for all requests triggered by developer (init, connect, login etc). Second one is used for miscellaneous internal functionality (e.g. encrypted cache).
Once again - this is a hack, definitely not a solution. Use with caution if at all:)
How About this,if we define our own function that will call some static properties and update them ?
function changeServerUrl(serverURL) {
WL.StaticAppProps.APP_SERVICES_URL = serverURL + WL.StaticAppProps.POSTFIX_APP_SERVICES_URL;
WL.StaticAppProps.WORKLIGHT_ROOT_URL = serverURL + WL.StaticAppProps.POSTFIX_WORKLIGHT_ROOT_URL;
WL.StaticAppProps.WORKLIGHT_BASE_URL = serverURL;
}
and call it
chnageServerUrl("http://"+yourServerIP+":"+PORT);
if you dig into the worklight.js file there is a function "setWLUrl(url)" that can be use to change the serevr URL.
call it like this and its done
setWLUrl("http://"+yourServerIP+":PORT");
its kind a hack but i think it should not have anny issue since its a function within there api.
Good Luck