The following link indicates that the security can be disabled using #OAuthSecurity(enabled=false) - see under "Security configuration of a JAX-RS resource"
Question:
Does it mean that the default security is disabled?
I have a scenario wherein a JavaScript Adapter (developed and being used in a previous version of the product) is auto-deployed on an upgraded server (from 6.1 to 7.0) - using in-place upgrade. This JS adapter had no security tests defined and as such was not protected.
Question:
When the adapter runs on 7.0 - does the out-of-the-box default security take effect? If so, how does one disable it?
Thanks, in anticipation.
Starting MFPF 7.0 there are two authentication models:
Classic: as you know it from pre-7.0 versions
OAuth-based
If your adapter is developed in the Classic way, it continues to work as before. If you want a procedure to have no security defined for it, not even the default internal one (when not setting a securityTest), use securityTest="wl_unprotected".
#OAuthSecurity(enabled=false) refers only to Java adapters whereas you are asking about an existing JavaScript adapter... or not?
Related
I'm developing an app with IBM MobileFirst Platform and I find an issue with Worklight.js file. Worklight.js is extending Function prototype defining several methods like bind, curry, wrap and so on.
My app is built with aurelia framework an after upgrading the framework to the last version I'm facing a funky issue related to bind extension.
If I comment the bind extension in worklight.js everything seems to work like a charm (don't know why worklight implements its bind version).
Worklight.js file seems to be added to the wlapp package at build time. Is there a way I can override this file so I do not have to modify .wlapp file each time app is built?
Thanks
The direct answer to the specific question you've asked is, no, there is no way provided to override worklight.js. This is the core JavaScript code needed for the MobileFirst Platform client-side to function, and as such the user isn't given any means to modify it - it's injected into your app (i.e., into the WLAPP file) during the build process.
I'm not aware of any specific issues with Aurelia, but have certainly seen cases in the past where an app that uses two different frameworks (e.g., MobileFirst Platform / Worklight, and something else) "fight" with each other because they both want to implement extensions that are not compatible with each other - in which case, one framework or the other usually needs to change to accommodate the other.
If you are a customer with paid support, I'd suggest opening a PMR so we can get our developers to take a look at the issue.
I have the same problem with Angular. Worklight bind makes Angular controller fail to instantiate. The solution is to recover the bind function after worklight is loaded.
var bind = Function.prototype.bind;
window.wlCommonInit = function() {
Function.prototype.bind = bind;
};
I'm studying the new function provide by 6.3 - Offline Authentication by this document,
https://developer.ibm.com/mobilefirstplatform/documentation/getting-started-6-3/authentication-security/offline-authentication/
and I'm getting a Error from the Adapter,
it's said #78 getInfo is an object, not a function,
Any help ?
Many thanks.
Note that this is not "new functionality". The sample project simply implements one possible way to achieve offline authentication.
I have tested the application by following the below scenario and it is working OK, so you really need to actually mention what you're doing, how you're doing it, what is the scenario and what exactly is the error (copy/paste it).
Steps:
Import project to Eclipse
Start the server (servers view > play button)
Deploy adapter
Deploy project and open in Xcode, install on device
Login when online (for example, using A/A as the username/password)
Logout
Move to airplane mode
Try to login again with A/A
The application successfully logged-in in 'offline mode'.
I'm using worklight application management features from an Android native App.
I want that when in the console the application status is changed to "Access Disabled" the only option for the user will be to quit.
In the Knowledge Center and in Developer works there is documentation about how to do it:
http://www-01.ibm.com/support/knowledgecenter/SSZH4A_6.2.0/com.ibm.worklight.appadmin.doc/admin/t_denying_access_to_older_app_versions.html?lang=en
https://www.ibm.com/developerworks/community/blogs/worklight/entry/how_to_create_a_customized_remote_disable_behavior?lang=en
It is explained that you must set a specific value for the initOptions object used in the WL.Client.init() method.
But in the Android native API I have not found the way to set the initOptions. The init method is deprecated and it does not accept initOptions.
Also, in case of Remote Disable the ResponseListener used in the WLClient.connect(aResponseListener) is not invoked, success or failure, no method is executed. Is this working as designed? I would expect a failure or success but not nothing.
Is it possible in a native app to force the application to close in case of Remote Disable?
How could I handle this situation manually in the app?
Unfortunately I do not have an example for you, but this is the general idea.
See if you can work with it (if someone can produce an example - please do...):
You need to create your own Remote Disable challenge handler that will extend the default Worklight Remote Disable challenge handler (RemoteDisableChallengeHandler.java).
class MyRemoteDisableChallengeHandler extends WLRemoteDisableChallengeHandler
Then you need to implement your custom logic in MyRemoteDisableChallengeHandler
WLClient.registerChallengeHander(new MyRemoteDisableChallengeHandler())
This will override the original.
You'll need to create your own dialog with a Quit button.
Some additional documentation.
For handling MaM configurations, this is, when you configure the app as Lost, Stolen, etc, in the Worklight Console -> Devices tab you must install the Fix IF201408281937 (Worklight 6.2) or later.
This events are also handled with the ChallengeHandler registered for the realm "wl_remoteDisableRealm"
We have already delivered the 1.0 version of our Worklight application. By mistake we have disabled the Direct update feature by updating the attribute "connectOnStartup = false"
We dont want to redeploy the application to markets (AppStore/GooglePlay) again, but wanted to make our users to utilize the direct update feature. We do have the access to WL server.
Our issue is little different from the one which is already discussed here "IBM Worklight - How to disable Direct Update?"
How can we provide the direct update feature to our end users without redeploying the application to AppStore/Googleplay. And just by changing the Webresources of the application.
We are using the adapters in our application but no where we are explicitly calling the "WL.Client.connect".
The Direct Update feature is always enabled by default.
You need to edit your question and explain what it is you've done in your Worklight project.
The feature will not work if:
You have set connectOnStartup:false
You are not using WL.Client.connect
You are not invoking adapters
You disabled it via the checkbox in Worklight Console
Otherwise, the feature will work, and a check for Direct Update will be performed:
On application startup
On return to foreground
The application will need Re-deployment on the App stores.
So the solution to your problem is
Rebuild the Application with connectOnStartup:true.
Redeploy the Application on App Stores
Once the users download the updated application, future updates will go to the users directly.
While rebuilding, make sure that you change the Version of your application within ApplicationDescriptor.
I am trying to install a privileged helper tool to perform some elevated work. I am using SMJobBless for the same.
I am able to install the tool fine and also able to communicate with it. I am using Mac OS X 10.8.4 and using NSXPCConnection for the same.
I have added .mach service in the plist which will be installed in /Library/LaunchDaemons. I am using [initWithMachServiceName:options:] in the app as the helper is privileged tool and [– initWithMachServiceName:] in the helper to listen. The communication is working fine.
But the problem is I tried the same communication with another application I created which did not have any codesign at all (the helper tool installer earlier was codesigned). I tried to connect to the mach service of the helper tool and was able to connect easily. This is a problem because anybody can communicate with it then and make it do anything.
I wanted some way to securely communicate between my application and the helper tool.
Thanks a lot.
As you've said that you're not signing the second app, I believe that that is the problem that is allowing a 2nd app from calling the helper application. From the Apple docs and specifically the ReadMe file in SMJobBless, it states: -
The Service Management framework uses code signatures to ensure that the helper tool is the one expected to be run by the main application
This document should be able to assist you in getting the helper app correctly associated with its owner.
Note that it references a python script, which is provided here.
Answering my own question: I had logged a radar bug for the same and Apple said that the behavior was intended:
"It is up to the privileged helper to not expose insecure operations"