Is there any way to avoid that the log in screen appears after updating a Worklight application when the user is already authenticated?
This scenario is not possible in Worklight 6.1
In Worklight 6.2, however, Direct Update will appear before any user authentication (as its default behavior - changeable). Therefore user authentication will be done only once.
Worklight 6.2 is expected to be released in June.
Related
I'm currently working on fixing a connection between a MVC4 application and IBM Cognos 11 application.
Previously, when moving between the MVC app and Cognos 10.2, we would redirect the user with their authentication within the URL. This wasn't desired but was how the system was set up initially when our team received the project.
Our team has now upgraded to Cognos 11. In doing so, we've lost the usage of this previous redirect (we get an error and the user isn't authenticated into Cognos).
My question is, is there a way to authenticate a user without installing the Cognos SDK (we have it but have yet to integrate it)? I was looking into the REST URL that it uses but it appears that to consume it, I need to have the SDK to do so.
It sounds like the Mashup Service may be what you want, that's a REST-oriented interface that supports authentication and doesn't require you to install the SDK. Here's a link that discusses how to login to Mashup Service:
http://www-01.ibm.com/support/docview.wss?uid=swg21660206
I tried the URL in that technote to get a description of required credentials on a Cognos 11 environment, and found that I had to tweak it because we aren't using a gateway web server. I found I needed to add a port, and omit /ibmcognos, so the URL that worked for me was more like
http://[ServerName]:[Port]/bi/v1/disp/rds/auth/logon?xmlData=
Finally, for more doc on Mashup Service, go to
https://www.ibm.com/support/knowledgecenter/en/SSEP7J_11.0.0/com.ibm.swg.ba.cognos.ca_dg_cms.doc/c_rass_gs.html
I know logout desn't work for Java adapter in Worklight 7.0, and found that it still doesn't work in Worklight 7.1. Is there any good work-around to discard an authenticated session?
You are not explaining what you're doing nor where you're doing it as well as did not provide a single line of code (you can use any service that hosts files to host your code)...
Therefore, I can only direct you to the following answers:
MobileFirst OAuth and Logout
MobileFirst OAuth Logout, cached OAuth indentity
I am using IBM MobileFirst platform 7 to develop a hybrid application for one of my clients. I am using the below environment setting to protect the app so that on app launch when it connects to the MobileFirst server, app will receive a security challenge from the server.
<iphone bundleId="com.AppTest" version="1.0" securityTest="mobileTests">
The app handles the challenge by showing the login screen to the user. I am using adapter based authentication for the app. This is working fine.
Problem with the above setup: There is a 'New user sign-up' link in the login screen that redirect the user to a sign-up screen. On load of the user sign-up screen, app is invoking an adapter procedure to get some data. The adapter procedure invoked from the sign-up screen is not protected with any security test.
Even though the adapter procedure is unprotected, the above setup doesn't allow the app to invoke the procedure before a successful user authentication. Server is throwing a challenge back to the app when the user clicks on the registration link and he stays on the login screen.
Does MobileFirst authentication framework provide any option to explicitly bypass the security check for specific resources while using environment level protection? I have gone through the platform documentation and couldn't find any such options. If anyone faced a similar problem and resolved it, could you share your suggestions on handling this please. Thanks.
The adapter procedure invoked from the sign-up screen is not
protected with any security test.
Does that mean that the specific procedure has no securityTest assigned to it? If so, you can try setting it as securityTest="wl_unprotected". Even if not explicitly setting a securityTest, there still default security assigned internally. To disable that try the mentioned wl_unprotected suggestion.
Read more here: Understanding predefined Worklight authentication realms and security tests
Setting securityTest value to wl_unprotected means that the resource
will not be protected by any of Worklight platform security
mechanisms. This security test cannot be used to protect application
environments and event sources as they both require user and device
identities. Usually this security test is used to protect adapter
procedures that should be publicly accessible without any
authentication requirements.
WL.Client.InvokeProcedure is an internal API and used by Worklight Framework, however, you can call this API after connecting a device in Debug mode with Google Chrome. How can we restrict the access to WL.Client.invokeProcedure so that a user is not able to Exploit this call?
Steps to replicate (for Exploitation Only):
1. unpack an APK built by Worklight
2. Set the android:debuggable=true (also check how WL Adapters are being called in JS files)
3. Rebuild the APK
4. Install the APK in mobile
5. Start the Application and connect through Chrome://inspect
6. Authenticate as a "normal" user
7. Go to Developer Console
8. Invoke WL.Client.invokeProcedure for any adapter you are authenticated, but with unauthorized User Data
I think the test is a bit misleading since "you" as an attacker will have several prerequisites: have the technical skill of manipulate code, invoking code and know what is a "normal" user.
That said:
In the upcoming MobileFirst Platform v7.0 you will be able to obfuscate the code of a mobile app (iOS, Android and so on). You can also do this manually now.
Already now you can enable the Application Authenticity Protection feature as well as the webResourcesChecksumTest and webResourcesEncryption features. See the security element section in the Application Descriptor user documentation topic.
The above will add several layers of protection to your application, either preventing tampering with the application code, not allowing to use the app if its checksum has change and verify the application identity.
I am developing a mobile application using Worklight, in which when a user signs in after authentication he should not sign in again and again. Could you please tell me how to keep the user logged in?
Check out the 'Form based authentication in hybrid applications' project in the Getting Started page: http://www.ibm.com/developerworks/mobile/worklight/getting-started.html#GS_security
There is also another feature of Worklight called 'heartbeat' which keeps your session alive by sending a simple request to the server. This also happens automagically without need configuration. It can be configured see here for more information (http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/index.jsp?topic=%2Fcom.ibm.worklight.installconfig.doc%2Fadmin%2Fc_optimizing_and_tuning_of_ibm_wl_server.html&resultof%3D%2522%2568%2565%2561%2572%2574%2562%2565%2561%2574%2522%2520).
Can you give more context to your question so the community can help figure out the problem? What version of Worklight are you using?