I have a unity project and contact an API for collecting data.
In the Editor, Android build, iOS build and Windows build everything is working fine. But the build for OSX gives me errors:
SSL: certificate subject name 'com-linweb061' does not match target host name 'ava-trix.com'
But the common name in my certificate is *.ava-trix.com, as you can see here:
https://www.sslshopper.com/ssl-checker.html?hostname=https://ava-trix.com
I have no idea what the problem is here. Can anyone help me out?
I was using Unity 5.3.5 wich, apparently, has an SSL problem for 32-bit OSX builds. So I created a 64bit version and the problem was gone.
Related
I have a gradle-managed project which I have been working on for the last few years. The code is published to an artifactory instance, which was migrated, company-wide, to AWS recently.
Ever since then I have been facing the following issue whenever I try to do a gradle sync for the project, rendering development impossible:
javax.net.ssl.SSLPeerUnverifiedException: Certificate for artifactory.domain.us doesn't match any of the subject alternative names: [*.domain.space]
I have tried the following:
Updating the intellij IDE to the latest version
Using local gradle distribution instead of built in wrapper (latest version)
Updating my jdk from 8 to 10 and then going back to 8
Copying the certificate of artifactory.domain.us from the browser to the jre's cacerts keystore using the keytool
Enabling and disabling various JVM and gradle VM related to tls and ssl ignore
Since no other developer in my team is facing this issue, it is probably a bad configuration from my end, but I can't figure out what. Please help!
In my project even if i change my server host using build settings and deploy target , the client properties does not change in the wlClient.properties file , however the context path changes to new one, the server host url is pointing to my local host now ,also one thing i have noted that wlBuildId this property is missing in the file
My version is :7.1.0.00.20150901-2103
What i have done :
Changed the server url in Right click > Run As > Build setting and Deploy target and rebuild the project even after rebuilding the wlClient.properties file the wlServerHost property doesn't change
Attached the settings screen along with this
I finally tracked down the problem , actually it was a bug in the build i have installed.
I installed the mobile first plugin from eclipse market which was of version 7.1.0.00.2015 which has the bug, then i removed the plugin and downloaded the package from IBM Mobile firsts website which was of build version 7.1.0.00.2016 which has the fix for this bug and it is rectified now.
The point to note is that the package in the eclipse's market has to be changed to the new build in which the issue is fixed.
Thank you
I have a Worklight 6.0 project that uses the new Dojo 1.9 libs, I created an external dojo project, like the documentation suggested, then, in the main project properties, under "Dojo toolkit", it references this dojo19 project.
The project works on the local server, then I did "Run As" | "Build for Remote Server...", and entered the correct domain:port and context path, clicked Build, the *.wlapp files were updated. (I've also updated the settings for publicWorkLightHostname / publicWorkLightPort / publicWorkLightProtocol in the "Environment Entries for Web Modules" in the installed war to match the remote server names/port/protocol.)
But, after deploying both war and -all.wlapp file, accessing the app I get JS errors when it tries to refer to the dojo19 library:
The page at
https://<myIP>:9443/<myproject>/apps/services/www/ /mobilewebapp/default/IODMobile.html
ran insecure content from http://localhost:64441/dojo19/<myproject>/IODMobile/mobilewebapp/dojo/nls/core-web-layer_en-us.js.
The dojo19 is the project name in my Worklight developer workspace that I referred to above.
Why is it trying localhost? Seems there's a missing step here in deploying the dojo library project into Worklight.
Where are you trying to preview the application when you get the error message?
See the changes in Dojo in Worklight 6.0
If launching the application in emulator/simulator/device, see Billy Rowe's answer in this question
Partial copy/paste:
Step 1: Verify your application works in the Mobile Browser Simulator
with Provide Library Resources checked. If the Console log is showing
resources being served from the server, then these have to be copied
to your application before deploying to AVD or a device
Step 2: After you think you have all Dojo/resources within your
project, uncheck Provide Library Resources and test it again in MBS.
If it fails in MBS, then something is missing in your application that
is in the library/server. You can check Provide Library Resources and
retest to see if it shows you what that is. Not all resources are
shown, e.g. if there's a missing CSS file.
Also I would suggest to do all of this in the Development environment (that is, in Eclipse) before starting to deploy the .war file and .wlapp file etc... (which, BTW, I hope you're doing based on the new instructions for Worklight 6.0)
In the information center, it will show you how to uncheck the Provide Library Resources in the Console Log.
I think what you're running into is:
1) Something is being served from the Dojo Library/Server
2) A bug in 6.0 that used "localhost" instead of the IP of the host (your machine running eclipse). This is fixed in the 6.0 iFix. With this fix, you can run your app external to Studio and still use the Dojo Library/Server. Without this fix, you must have everything you need within your app.
Can you install the iFix and let us know if that fixed the problem?
I've just installed Worklight 6.0 on Mac OS X Mountain Lion 10.8.4.
I'm trying to build a very simple HelloWorklight app to test the installed environment and I'm getting errors building and deploying it.
I'm getting these errors in Eclipse console:
[2013-07-13 02:11:21] Starting build process: application
'HelloWorklightApp', all environments
[2013-07-13 02:11:21] Application 'HelloWorklightApp' with
all environments build finished.
[2013-07-13 02:11:21] Deploying application
'HelloWorklightApp' with all environments to Worklight Server...
[2013-07-13 02:11:21] Failed to deploy the application to
Worklight server: Worklight module
HelloWorklightProject was not
successfully started. Full details of the error are available from the
Worklight Development Server console.
The Worklight Development Server console in my browser shows:
Application Error
SRVE0777E: Exception thrown by application class
'com.worklight.core.auth.impl.AuthenticationFilter.doFilter:110'
javax.servlet.ServletException: Worklight Project not initialized
at com.worklight.core.auth.impl.AuthenticationFilter.doFilter(AuthenticationFilter.java:110)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:194)
at [internal classes]
I'm truly stuck. On the other hand I'm sure it must be something simple to fix it.
Has anyone got an idea how?
I had a similar problem (at least WDS console error looks the same).
A little bit history:
My problems started, when I updated Worklight to version 6 (with version 5 I had no problems). Some compilation erros were fixed by adding Websphere Library to a project. But my custom authentication still wasn't working.
How I fixed it:
open new workspace in Eclipse
import Worklight project
clean project
restart Eclipse
downgrade compiler compliance level (in Eclipse: Window > Preferences > Compiler and set "Compiler compliance level" to lower version)
rebuild project and try to run it
At this point it started to work. I've spend lots of time to find out that compiler stuff, but still I'm not sure which part requires that.
So we had this issue with 2 macs and it took us a solid day and a half to figure it all out.
We went through a lot of reconfiguring, re-downloading eclipse and worklight.
Make sure your config files from the update are correct. (worklight.prop and authConfig)
This is the big one. Install JDK 1.7 and reference the new JRE 7. When we
were running on Oracle JRE 6, we had a ton of errors and even a Java
Heap memory issue.
Once you install it, it may to be tricky to find the actually path to the JRE.
First, go to Eclipse > Pref > Installed JRE's > Add
Then, add a new standard vm. Click Directory on the next pane and browse to the install path of JRE.
We found it in [name of your HD] > Library > Java > JavaVirtualMachines > jdk1.7.0_25.jdk > Contents > Home > jre
It should load everything it needs and you can click the check box of the new JRE. For good measure, I changed the compiler to 1.7 as well.
The jdk folder may have a slightly diff name depending on what update you have. Hopefully this helps.
I got the same error after deploy an new app deployment.
What I've done on Server is:
delete all application
delete all extra configuration between new server instance and my current instance. In my case it was: applicationMonitor and shared librairy
clean
restart
After that I managed to deploy my application normally
window -> show view -> servers -> server configuration -> HTTP EndPoint -> host
By default the host will be *. Try to change the host as your local machine ip address. for example host = . After changing the host, close the server.xml and then try to rebuild the project.
In my XCode project, I have 4 different Build Configurations: Production, Development, Staging, and Staging2.
In my Build Settings, I noticed Validate Built Product is set to No for all configurations. If I switch them to Yes, I then get a warning each time I try to build:
Application failed codesign verification. The signature was invalid, contains disallowed entitlements, or it was not signed with an iPhone Distribution Certificate. (-19011)
I'm still able to build on to the phone and create Archives though.
At least for production, I'd like to turn Validate Built Project to Yes, but I don't want to see that error each time.
How can I make codesign happy?
Note: I recently upgraded to XCode 4.6, reinstalled the command line tools, and updated my project settings when XCode prompted me to do so. I confirmed that I had Production set to Yes all along, which tells me something with this upgrade is causing this error.
Also, I've read this support doc pretty thoroughly, followed all the steps, and it seems as though everything was correct to begin with.