I have a process that utilizes the Banno Alert API call. In testing, it was working fine. All of a sudden, the test messages stopped coming through despite the API returning a successful code of 200 with an associated AlertID.
Looking in my Banno test app as well as the Admin backend site, there is no message sent to my account and I did not receive a push notification. I tried sending a test message to another user who was successfully getting the message and push notification earlier. He did not receive a push notification but the message does show up on his account.
I've tried changing the text of the title and body in case you can't send the same thing twice. I also tried waiting a day in case there was a system issue causing this problem but I am encountering the same issue the next day. Is there something that m
Related
I am using Apereo CAS 6.3.3 generated by CAS Overlay project.
The integration with the application and LDAP is working well, but there are two problems that I have noticed. These problems are random and happens only with 20% of the requests.
1.) If someone directly accesses the CAS log-in page with ?execution=anything , the page shows the following HTTP 500 error.
org.springframework.webflow.execution.repository.BadlyFormattedFlowExecutionKeyException: Badly formatted flow execution key 'anything', the expected format is '_'
Is there anyway the error can be disabled and instead the page is redirected to application log-in page instead.
2.) Is there anyway the too many redirects error can be disabled for the expired service tickets so that the end user is redirected to the login page instead of first seeing the error message on the browser?
Thanks.
Is there anyway the error can be disabled and instead the page is redirected to application log-in page instead.
Applications that integrate with an SSO solution such as CAS do/should not have their own log-in page. After all, that's why they use CAS.
That said, to handle this error, you'll need to modify the CAS login webflow, and have it properly catch this error using what Spring Webflow calls Global Exception Handlers. Only then you can decide how to respond and handle the scenario with bad flow execution states.
Is there anyway the too many redirects error can be disabled for the expired service tickets so that the end user is redirected to the login page instead of first seeing the error message on the browser?
Yes. There is.
You need to get the application to respond correctly to failed validation attempts. If it sees a validation failure due to an expired ticket, the application should honor the failure, and ask for a new non-expired service ticket.
You may also need to adjust the service ticket timeout; perhaps there is lag or delay such that the ticket is seen as expired by the time it reaches the application, and is sent back to CAS for validation.
The best way to stop an infinite redirect loop is to stop the entity that is causing or sending those, and correct the mistake rather than hiding it with an error message. That's just an aspirin, and while it helps, it does not treat the underlying problem.
to the login page instead of first seeing the error message on the browser?
There is no login page, or the browser to redirect to. The failure is the result of a back-channel validation call. There is no browser.
I’m developing chrome push notification for my web site and doing the development in localhost (local machine) environment. Sending push notification is success with specific endpoint which I got when I subscribe the notification first time. I use same endpoint for all push messages.
Here sometime push notification got failed due to endpoint mismatch. When I see in chrome console (debugging mode) there was different endpoint.
Why chrome browser is changing endpoint? In this case how do we handle this scenario and update the new endpoint in the db?
sample endpoint:
https://android.googleapis.com/gcm/send/AWERdvfdfdsfdobRH4zlXGuyeuie3543uTBuP6air5dzZfltNa-FKF6K6S-9P5SdfbCbyvn9RdsfsdvU1XwSBwIrekjdK6_i4Cg-5rZAj8UvL1s-Bbr61yvvt_y2Hg9RdsyV
when i check next time, above endpoint got changed as like below
https://android.googleapis.com/gcm/send/reytryMkQwtY:YTUNMdsjjfhsdf349851VS6McDE7s_GITe_djsgfdkjghcdfdfgdftrkddfdsXiwX1vP_XclmDqrKPOAMJDfsYYXdhMX164694Q&ksdhfksdfhkjfhksdcndsk
Thank you.
The push notification endpoint is dependant on the service-worker. When a service-worker is unregistered and created again, the PushManager.getSubscription() method will indeed return null. You then need to call subscribe() again, which will return a new endpoint.
If you server tries to send a push notification to the first endpoint after the service-worker was unregistered, you will get a NotRegistered (for Chrome) or a Gone (for Firefox) error. So make sure to register the new endpoint as soon as the app loads or the device may become unreachable.
Note that this does not seem to affect service-worker updates.
I keep getting emails every night at around 8pm that Gmail Delay Send has failed and showing a summary of the failures. The error message says "Authorization is required to perform that action". Every night, there are 288 "failures".
Here's the thing, though- I haven't tried to use Gmail Delay send in roughly 6 months! Not sure what is going on, has my email been hacked?
This is most likely coming from an app that you authorized before.
"Authorization is required to perform that action" probably means you revoked the access to that app through your account dashboard and it's been trying to run.
If this is an app you created then you can visit the link in the mail and remove the triggers there.
I've been working on both the receiver and web sender (Chrome) apps for Chromecast for a while, and since the new API (publicly released yesterday) I've been unable to receive any media status updates after performing a loadMedia request.
Upon refreshing the page, I am able to receive the updates as expected, but both channels receive the media session object the exact same way and perform the exact same methods upon it (addUpdateListener)
We're working with an HLS stream on the receiver side, but I can see updates being sent out to the senders (and obviously they are, as a reload allows the web sender to receive them). Also, on the sender side, I can see updates when I perform actions such as play/pause/volume/mute and seek requests, but only one update after each action.
TL;DR: Don't see any regular media status updates for events such as loading->buffering->playing, and I also don't even see the play/pause/volume/etc updates from other senders connected to the session.
Here's all I get from the sender before it just stops sending any status updates:
[chrome.cast.ApiImpl] Getting message from extension:
{"type":"v2_message","message":{"type":"MEDIA_STATUS","status":[{"mediaSessionId":1,"playbackRate":1,"playerState":"BUFFERING","currentTime":500,"supportedMediaCommands":15,"volume":{"level":1,"muted":false},"media":{removed}","streamType":"buffered","contentType":"contentType","metadata":null,"duration":1450.1558329999993,"customData":null},"sessionId":"FD5AA3F0-F93C-050A-4900-7C6D916525BA"}],"requestId":92278937},"seqNum":"a14772002","clientId":null,"appOrigin":null}
[chrome.cast.ApiImpl] Creating new Media object:
FD5AA3F0-F93C-050A-4900-7C6D916525BA:1 cast_sender.js:3428 New media
session ID: 1 (loadMedia)
But I can tell that the receiver is still sending out updates by looking in the debug console, there's a bunch of these firing off:
[245.485s] [cast.receiver.IpcChannel] IPC message sent:
{"namespace":"urn:x-cast:com.google.cast.media","senderId":":","data":"{\"type\":\"MEDIA_STATUS\",\"status\"
...removed [247.495s] [cast.receiver.MediaManager] Sending broadcast status message
I've also noticed that when I do get messages prior to the loadMedia callback, they're all in the BUFFERING state, never a PLAYING
This bug is confirmed and it has been fixed as of Feb 10 update of Cast extension.
Old workaround:
For now there is a workaround for this type of issues where status updates from receiver apps are routed to Chrome Cast extension but not getting routed to the Chrome sender apps.
The trick for now to see incoming status updates from receiver apps is to open up at least 2 tabs that run the same sender app. You initiate a session from one of the tabs and then join that session from the other tab. Now any status update messages from receiver app will not be intercepted by the Cast extension anymore.
I see this bug has been fixed with Feb 10 update, however I am not seeing currentTime event. From the docs -
Changes to the following properties will trigger the listener: currentTime, volume, metadata, playbackRate, playerState, customData.
Should we expect to get an update when the time changes?
We currently have an implementation that uses boxes API. Our authentication process follows the process outlined here:
http://developers.box.com/get-started/#authenticating
Sometime in the recent past this has stopped working. When we go to the oauth URL (for example, https://www.box.net/api/1.0/auth/rev37d850p6pixlemm5ok8doxj2g77kg), it will initially show the login credentials page, but faster than a user could reasonably enter their credentials the page starts returning "expired ticket". If I immediately go to the token's page after creating it I can reload the page a few times before it goes into the "expired ticket" state. This is clearly not consistent with the expected 10 minute expiry time stated in the documentation.
We've had this authentication working correctly up to now, so it seems like something has changed.
We are investigating. More news once we have some additional information.
New info>> We've identified the bug, and will be pushing a fix this afternoon.
The fix has been rolled out. Please let us know if you are still experiencing any problems with SSO.
Our Android app has the same problem. As far as I investigated it, using get_auth_token API causes the ticket to expire. So you have to make sure the user has successfully logged in BEFORE attempting to get the authentication token (which is not the case with Box SDK for Android). But I don't see a viable way to check whether the user has logged in.