been experimenting with UE5 and EOS
I havent filled in the branding section completely in the dev portal for EOS (in draft) as I dont have a policy or game logo
I have the game logging in fine (using accountportal) and that returns success and I get the overlay, so no issues, but when I try and create a session it fails with the below Error
[2022.05.07-10.50.43:574][724]LogEOSSDK: Warning: LogEOS: Error response received from backend. ServiceName=[Sessions], OperationName=[CreateSession], Url=[], HttpStatus=[403], ErrorCode=[errors.com.epicgames.common.policy_missing_action], NumericErrorCode=[UNSET], ErrorMessage=[Client missing matchmaking:createSession], CorrId=[EOS-Cq8EcZDt1UCJ_3H0vBAlMw-P4g0uuJPKUeOfcjLzhEBIQ-p7QMqQjV-EyAynCi_1iBjw]
If I set the "isLan" option it works fine no issues, have I missed something in the setup to stop it working online or is it because the branding is in draft and not verified that it only allows Lan?
This was potentially due to the online portal client policy, was pretty sure I had it so the client to create/host sessions but i went through it all again and now it seems to work
Related
I have perl on apache http service that's been working fine for several years to issue sonos cmds and receive callbacks. About two weeks ago, I stopped receiving any callbacks.
I subscribed successfully (response={}) for groupVolume, playbackMetadata, and playback events.
I am successfully getting webhook messages from other services (e.g., Vonage) using https, so it seems the port is open to my server, and apache is successfully processing these requests. I see no trace of any messages from the sonos api in my apache logs.
I have no trouble issuing commands (setMute, getFavorites, getPlaybackMetadata, etc.). Only the callbacks are a problem.
I ran the ssltools checker from digicert but found no issues.
I can't recall making any changes to the home router config.
Does anyone else have a problem like this or know how to diagnose what's happening?
I installed WireShark but am overwhelmed with the functionality and don't know how to narrow down what I should be looking for to see if the messages are being received and blocked somehow.
it may be unlikely, but is it possible that there isn't any usage of your integration that would result in callbacks being sent to your service? For example - if volume isn't being changed, or playback isn't happening, you won't receive events.
If that's not the case, additional information is required to debug this issue. Could you please email developer-feedback#sonos.com with the following information:
The name of your service/application
The date/time your service stopped receiving callback events. You said about two weeks ago, but could you be more specific?
The clientId used by your code. This is the UUID you generated when you initially created the "API Key" on developer.sonos.com. Format is xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (note - we do not need the secret associated with this key).
With that information we should be able to determine the cause of your missing callbacks.
I've installed FusionAuth (awesome product) into a Docker Swarm cluster using the official docker-compose.yml file and everything seems to work brilliantly.
EXCEPT
Periodically, when a user goes to login they will be presented with the above error stating that the search engine is not available. If they try again immediately then everything works correctly! I would, obviously, prefer that they never saw the error.
Elasticsearch is definitely running and is responding to API calls correctly, and I can see the fusionauth_user index is present and populated with docs.
I guess my question is two fold:
1) What role does the ElasticSearch engine play in the FusionAuth ecosystem and can it be disabled?
2) Is there a configurable timeout somewhere that is causing the error message and, if so, where can change it?
I've search the docs for answers to the above but I can't seem to find anything :-(
Thanks for the kind feedback.
1) What role does the ElasticSearch engine play in the FusionAuth ecosystem and can it be disabled?
Elasticsearch provides full text search of user data. Each time a user is created or updated the user is re-indexed. In this case during login, we are updating the search index with the last login instant.
This service is required and cannot be disabled. We have had clients request to make this service optional for embedded applications or small scale scenarios where Elasticsearch may not be required. While this is not currently in plan, it is possible we may revisit this option in the future.
2) Is there a configurable timeout somewhere that is causing the error message and, if so, where can change it?
Not currently.
Full disclosure, I am not a Docker or Docker Swarm expert at all - perhaps there are some nuances to Swarm and response time due to spin up and spin down of resources?
Do you see any exceptions in the log when a user sees this error on the login?
What would be the best way to debug Parse Cloud Code? Currently it's a mess of logging to the console and checking logs. Does anyone have a good workable solution?
During development, you should begin by testing against a local hosted server. I.e., I use VS Code. You can set breakpoints and watch variables for their values. You can set up a tool like ngrok to get a remote URL for your local endpoint so you can test with non-local hosted clients if you'd like.
We also use Slack extensively. We've created our own slack bot, and it has several channels it reports relevant information too, triggered from our parse-server. One of these is a dev error channel. Instead of console.logs, which are hard to sift through and find what you're looking for, we push important information to Slack. We don't switch every single console.log to a slack message, just the important "Hey something went wrong here's the information" messages. This brings them to our attention so we can identify and resolve them way faster. Slack is awesome. I recommend using slack, even on a solo project.
at the moment you can access your Logs using a console.log() or console.error() for functions and all general logs of everything that happens with your app, at Back4App you can access using: Server Settings -> Logs -> Settings -> Server System Log.
Or functions and all logs generated by Parse server, they're: request.log.info() and request.log.error(), at Back4App you can access using: Dashboard -> Logs.
I am using a java raw HTTP client to connect to Shopify API (specifically, using Play Framework with the non-defualt sync driver which is actually the JDK's default driver).
My application usually manages to connect successfully and convert the temporary access token into a permanent one by calling the /admin/oauth/access_token endpoint.
However, sometimes I get this error result from the API:
Generic Error(400)
{"error":"invalid_request"}
I haven't been able to reproduce the issue with my test stores - I've tried installing a fresh store, reinstalling existing stores after uninstalling, I'm not sure why this call sometimes fail and how to debug it. The API call still continues to succeed for some stores using our application.
Some things that I am doing:
Even if the URL of the store is on a custom domain, I'm always using the https://foo.myshopfiy.com/admin/oauth/access_token URL and not the URL of the custom domain, to prevent a redirect.
I am always using an https URL and never an http one, again to prevent a redirect (we noticed a few issues with redirect with the Java HTTP client, so we aim to have zero redirects)
A thread I found about this error suggest possible problems with our SSL certificates, however I don't think this is my problem because some requests work for us, and the result of running openssl on our machine does't show any issues.
How should I proceed? Open a support ticket with Shopify?
FYI, I see that this specific problem only started yesterday on Feb 19 2013, so it might be a temporary issue.
FYI, the problem was caused by reusing a temporary access code.
Our fault - Shopify could have been more clear in their error message though.
We have recently upgraded from WebLogic Portal 9.2.3 to 10.3.5. We have a JackRabbit repository connected through the Day Software JSR-170 VCR-JCR provider. This has all worked perfectly fine on 9.2.3, but on 10.3.5 we are getting a IllegalMonitorStateException when we try to retrieve content. We have out own facade on top of JackRabbit, that implements the JCR-170. Here is the debug out from the server:
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.initializeSessionState():1215] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2b70161: (re)initializing all repo sessions for username: <WLS Kernel>
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.initializeSessionState():1215] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2bf2311: (re)initializing all repo sessions for username: <WLS Kernel>
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.initializeSessionState():1215] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2fa5952: (re)initializing all repo sessions for username: <anonymous>
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.ensureConnectedToRepository():801] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2fa5952: no session found for repoName=indhold; need to connect
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.ensureConnectedToRepository():821] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2fa5952: connect write lock acquired for repoName=indhold
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.connectToRepository():875] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2fa5952: connecting to repositoryName= indhold
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.getRepositoryClass():1503] invoking Class.forName(repoClassName)
[com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.getRepository():1403] com.bea.content.federated.internal.delegate.RepositoryManagerDelegate#2fa5952: Ticket authentication error for: indhold java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:363)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1317)
at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:745)
at com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.getRepositoryClass(RepositoryManagerDelegate.java:1537)
at com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.getRepository(RepositoryManagerDelegate.java:1327)
at com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.connectToRepository(RepositoryManagerDelegate.java:893)
at com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.ensureConnectedToRepository(RepositoryManagerDelegate.java:832)
at com.bea.content.federated.internal.delegate.RepositoryManagerDelegate.connect(RepositoryManagerDelegate.java:1160)
at com.bea.content.federated.internal.delegate.RepositoryHelper.checkCapability(RepositoryHelper.java:759)
at com.bea.content.federated.internal.CapabilityManagerImpl.checkRepositoryCapability(CapabilityManagerImpl.java:57)
at com.bea.content.federated.internal.ManagerImplCapabilityHelper.checkCapability(ManagerImplCapabilityHelper.java:80)
at com.bea.content.federated.internal.ManagerImplCapabilityHelper.verifyCapability(ManagerImplCapabilityHelper.java:54)
at com.bea.content.federated.internal.NodeManagerImpl.getNode(NodeManagerImpl.java:432)
at dk.skat.portal.front.helper.ContentHelper.getNode(ContentHelper.java:1591)
It seems that authenticationn fails, but if I try to set a break-point in the login methods in the repository (our Facade, which doesn't do any authentication challenge, but just wraps JackRabbit, and logs in the same user - "default" - for all access), we are never getting called. Setting the username and password on the Manage Repositories page, doesn't seem to have any effect.
If I on the other hand go to Portal Administration Console, and try to manage or browse the repository, everything works fine, and the login methods are actually called, and the server connects fine to the repository.
This seems very strange. In cetain cases (that happens to happen randomly, we can get the server to all of a sudden get to the repository, but on restart of the server, it is again back to failing).
I've tried to set username/password for the repository to the weblogic user, but that doesn't seem to have any effect, I still get the error.
Furthermore when I've been into the PAC, and logs out, closes the browser, reopen the browser or a completely different browser, the entering of PAC seems to activate the repository to become online (though this is not stable or desired).
Please advice, if there is a bug in WebLogic (it seems it tries to unlock() the ReadLock too many times, resulting in the mentioned exception - should it at all fail on that exception??, Should the lock-count be checked before unlocking?), or if w are doing anything wrong? I can read that there is a known bug in the eclipse tooling for 10.3.5 about exactly this error.
Furthermore, we didn't seem to have any trouble in 9.2.3, what changed in 10.3.5?
Had same issue, found solution here https://forums.oracle.com/forums/thread.jspa?messageID=10984645
In short, it is a product bug, request following patch from Oracle:
WLP Version: 10.3.5
Patch Name/Patch Number/Bug Number: 14377862
Smart Update Patch ID: HPV8