WSO2 EMM version: 2.0.1
Database: MySQL
Scenario: BYOD (Non-supervised)
WSO2 EMM is not working after use upgrade iOS version. This happens when I upgrade the iOS version from iOS 9.2 to 9.3.
Exception on Server: "Data too long for column UNLOCK_TOKEN"
Class:org.wso2.carbon.device.mgt.mobile.impl.ios.dao.impl.IOSDeviceDAOImpl
I accidently deleted server log. I can't downgrade my iOS device & then try again.
Please help me. It's not WSO2's open-source class, so I can't compile & reuse it.
Please note that the EMM version 2.0.1 has not been tested on iOS 9.3.x (1) since the product relases was done prior to the iOS release 9.3.x release.
However the issue seems to be caused by column length of the column UNLOCK_TOKEN, that is too small to hold the token sent by iOS 9.3.x devices. As a solution, you can increase the column length of UNLOCK_TOKEN column in IOS_DEVICE table of the iOS related database.
(1). https://docs.wso2.com/display/EMM201/Prerequisites
Related
I would like to understand the hazelcast version being used with git release 5.11 https://github.com/wso2/product-is/releases/tag/v5.11.0
and where is it specified? Can I upgrade it to 4.2.4.wso2v1 to avoid the vulnerabilities?
Hazelcast is mainly used in the WSO2 carbon-kernel and simply upgrading 3.12.x to 4.2.x would result in issues as it is being a major version upgrade, there are set of API changes done from Hazelcast. This issue has tracked the effort of Hazelcast version upgrade on WSO2 products. You can port those fixes. Also note that WSO2 IS 6.0.0 has upgraded the Hazelcast.
I have this type of architecture- Tablet application,Desktop Application,web application.. In tablet application its sync framework 2.1.Desktop 2.0 web 2.0 When syncing from Tab to Desktop i am upgrading metadata to 2.1, sync works fine between tab and desktop...Now when trying to sync between Desktop and Web it throws error as metadata of desktop app is upgraded. I cant upgrade web metadata as many desktop users are using 2.0 framework in their desktop. can anyone suggest me wat to do in this scenario.
unfortunately, you can't mix and match the metadata version. its either you upgrade everyone or you don't. (i think that's actually explicitly mentioned in the metadata upgrade docs.)
We have recently received two alerts regarding our facebook app.
Your app is still calling Graph API v1.0 which will be
deprecated on April 30, 2015. You must upgrade this app to v2.0 or
greater before that date.
To help you experience the potential effects of this migration,
starting tomorrow at 12pm PST, the admins, developers, testers and
Test Users associated with this app will be upgraded to use API v2.0
by default. This change won't affect your public users until April 30,
2015.
You'll be able to temporarily opt-out of this behavior in the
Migrations tab of your app's dashboard - but the migration will be
automatically re-enabled every two weeks until April 30, 2015.
For more information, please read our upgrade guide and login review
guide.
The second one is very similar and starts with:
We have detected that your app is still calling Graph
API v1.0 which will be deprecated on April 30, 2015. You must upgrade
this app to v2.0 or greater before that date.
However, we have been using Graph API v2.2 for serveral months now by specifying api version in koala config (we always use koala to call GraphAPI):
Koala.config.api_version = "v2.2"
Since we need the subscribed_apps endpoint, we are using v2.2. Switching to v1.0 results in OAuthException, code: 12, message: (#12) Requires version v2.2 or higher [HTTP 400] in case of subscribed_app calls.
I know that not specyfing a version at all results in choosing the oldest available one but we have specified the version in koala, so it's not the point in our case.
Is it possible to find out what caused the alert from Facebook?
I have found an answer to my problem and would like to present all the facts.
For older applications you will see a different message, for example that your app upgrade is completed in 98%.
For applications created quite recently (mine was created in July 2014) that are already version v2.0 or higher you might receive an alert but the message you can check at https://developers.facebook.com/apps/upgrade/ says:
You do not need to upgrade any apps.
I also received a piece of advice from Facebook:
If you're confident your app is upgraded, you can go into the
Migrations tab of the Settings section of the App Dashboard - and flip
the "Use Graph API v2.0 by default" switch to "On" - then you can be
sure you're API migration is ready for April 30th.
If you don't see that setting then you're already using v2.0 or
greater, so you have nothing to worry about.
If you are sure that neither your server-side calls nor your client-side logins use version v1.0 or you chose option "Use Graph API v2.0 by default", you can assume that your app is ready for April 30th and ignore the alerts.
Here you can find some information about the bug that probably causes these alerts: https://developers.facebook.com/bugs/957020271005002/. This issue won't be fixed.
We are using WSO2 4.1.1 for user management. Is there a way to do a session time out in WSO2 4.1.1?
(I am looking if there is a fix for this in WSO2 4.1.1. Currently, I am not looking at migrating to WSO2 4.5
where this is mentioned as a supported feature).
I am referring to the following link where it says the WSO2 4.1.1.code has been changed to handle session time out.
https://wso2.org/jira/browse/IDENTITY-1030
Are these changes available as a new version of jar compatible with the WSO2 4.1.1 version?
Thanks in advance for the help
You won't be able to get a new version of the jar and use it with the WSO2 IS 4.1.1. AFAIK, IS 4.1.1 was never released, I think you are using a build shared via dev# list.
Anyway, you can try following.
Checkout the source for the corresponding jars in WSO2 IS 4.1.1. Try to checkout from branch. For example: https://svn.wso2.org/repos/wso2/carbon/platform/branches/4.1.0/components/identity/org.wso2.carbon.identity.base/
Fix the issue and do 'mvn clean install'
Copy the target jar as a patch.
Run server with -DapplyPatches
In this way, you can try to fix this issue.
If we discover issues with any product after it has been released, you will be able to get the fix only in a newer version. Otherwise, you need to patch the existing jar versions.
I hope this helps.
I would like to create a carbon server composed of multiple features; namely the User Engagement Server (UES) and the Data Services Server (DSS). UES is only carbon 4.1.0 based and DSS is 4.2.0 or 3.0.1 based. Is this possible? If so, how? If not, what are my alternatives for utilizing the functionality of both features set?
I have looked over wso2.org and other resources for help; however, I'm failing to find best practices for deploying a custom carbon solution and upgrading to future version. In another post I found a compatibility matrix, but the answer indicates that there is neither forward or backward compatibility.
WSO2 products will have API level changes between two different platform releases (as in 4.1.0 vs 4.2.0 [Turing]). So installing features from different platform versions will not work in most cases.
However, UES does have features based on a carbon 4.2.0 kernel (UES 1.0.1) and you can install the required features from the latest p2 feature repository here. It includes UES 1.0.1 feature which is based on Carbon 4.2.0 kernel. You might want to wait till DSS 3.1.1 is officially released (due to be released in about a week) which has some important bug fixes and improved stability.
To get features of both products, it would be easier to install UES features on top of a DSS product or vice versa, rather than installing both feature sets on a bare bones carbon server, since you may have to additionally install some kernel patches, configuration files, which are not installed during a feature installation.
HTH,