I'm trying to work through reconfirming a user who did not complete Cognito's verification code step, but I am hindered by an error reading "Attempt limit exceeded, please try after some time." I have tried deleting and recreating the user from the user pool, but the same error appears on the next test run.
Is there a way to override the attempt limit, either through the AWS console or some other means? The lockout period is an annoying barrier for testing, and I wonder if there is anything I could do if this scenario came up with a real-life user.
Related
In ABAP I can conduct authorization checks using the command AUTHORITY-CHECK. In case the user has the required privileges, sy-subrc equals 0. Otherwise, it is unlike 0.
I wonder if such failed authorization checks are logged somewhere since this can be interesting in terms of application security.
I am aware of the notion of security audit log, system log and so forth. However, I never stumbled upon the fact that such authorization checks are put there.
Also, I know the transaction SU53, however, I believe it does not perform any long-term logging activity.
Is there such a log that fetches all failed authorization checks?
If you switch on the authority trace in ST01 or STAUTHTRACE, the attempts (whether failed or passed) are logged. However, that is intended for development and debugging purposes only. Permanently logging all auth checks of all users may not only be significant performance issue and generate a huge amount of data in short time, but it may also be illegal as it constitutes a permanent surveillance of the actions and performance of the employees.
In my app (iOS) data upload (http post) sometimes fails (timeout) on bad networks (EDGE).
What is the best strategy for retrying?
Should i retry immediatly or should i wait for "better" network conditions?
How could that be achieved?
There are many ways to handle this, but which you choose very much depends on your application, and how critical the data you're posting is:
Assuming you're doing this in the background (asynchronously), just keep retrying until it works - maybe up to a maximum number of times.
Inform the user and ask them if they want to try again (let them know they need a network connection).
Store a cache of all un-transmitted data and try again after a period of time, or on app restart or when the app is backgrounded.
There's no best strategy - it all depends on the use case for your app.
I would suggest having first try as normal but when it fails, show a UIAlertView with message some thing like: "Couldn't connect to servers, do you want to try again". Place Yes and No button. And when user taps YES, give it another try.
I've got a JMS messaging system implemented with two queues. One is used as a standard queue second is an error queue.
This system was implemented to handle database concurrency in my application. Basically, there are users and users have assets. One user can interact with another user and as a result of this interaction their assets can change. One user can interact with single user at once, so they cannot start another interaction before the first one finishes. However, one user can be in interaction with other users multiple times [as long as they started the interaction].
What I did was: crated an "interaction registry" in redis, where I store the ID of users who begin an interaction. During interaction I gather all changes that should be made to the second user's assets, and after interaction is finished I send those changes to the queue [user who has started the interaction is saved within the original transaction]. After the interaction is finished I clear the ID from registry in redis.
Listener of my queue will receive a message with information about changes to the user that need to be done. Listener will get all objects which require a change from the database and update it. Listener will check before each update if there is an interaction started by the user being updated. If there is - listener will rollback the transaction and put the message back on the queue. However, if there's something else wrong, message will be put on to the error queue and will be retried several times before it is logged and marked as failed. Phew.
Now I'm at the point where I need to create a proper integration test, so that I make sure no future changes will screw this up.
Positive testing is easy, unfortunately I have to test scenarios, where during updates there's an OptimisticLockFailureException, my own UserInteractingException & some other exceptions [catch (Exception e) that is].
I can simulate my UserInteractingException by creating a payload with hundreds of objects to be updated by the listener and changing one of it in the test. Same thing with OptimisticLockFailureException. But I have no idea how to simulate something else [I can't even think of what could it be].
Also, this testing scenario based on a fluke [well, chance that presented scenario will not trigger an error is very low] is not something I like. I would like to have something more concrete.
Is there any other, good, way to test this scenarios?
Thanks
I did as I described in the original question and it seems to work fine.
Any delays I can test with camel.
My app has an API that users can request data. Sometimes that data takes time to process and is breaking my code.
I need a solution for this and I was thinking in using delayed_job but I'm not sure how this works. If the user makes a request, I need to give him an answer. Even if I process the data in background, the call still needs to wait until the job returns.
What is the solution for this? I am not sure how to do it.
Thanks
Heroku has a 30 second timeout, which is why your requests are failing (Probably H12 or H13 in your heroku logs).
There are three methods to work around this.
Keep the connection open by sending blank data.
You'll need to respond within the first 30 seconds and every 55 seconds after that. Use the time in between to process the data. Sending spaces should not affect the ability of the browser to read the response.
Callback
Have the user provide a callback URL in the initial request. When you finish processing the data, hit the callback url with your response.
Polling
As suggested by Codeglot, you can provide the user with a key. To check on their request, they can ping your server with that key.
Tell the user that their data is being processed and will be available shortly. Youtube, Vimeo, Facebook, Twitter, they all do this.
Good morning. I have an application that queries a REST source. It needs to run continuously, capturing data which is refreshed every five minutes, without fail. My solution is Task Scheduler, where the app is set to launch on server boot. Once launched, it uses a timer to re-query periodically. The TS task is set to repeat every five minutes, with the check box "if app is already running, do not start another instance," so if the app crashes it should restart automatically within five minutes.
This works fine, but TS launches the app invisibly. I'd feel warmer and fuzzier inside if I could see the app, just as if I'd launched it myself. Also, if I need to close it (e.g., to post a new exe), I have to kill it via Task Manager; ouch. I've gone over the TS options a dozen times for some kind of "launch in foreground" option, but none exists. Can anyone tell me what I'm missing?
Notes:
From my web searches, it's clear that an app is only allowed to interact with the desktop if it's running under the same user account... but it is, I'm using my AD account, not SYSTEM or another local account.
It's acceptable for the app to only be visible to me, though even better would be if other users could also see and interact with it. I suppose the only way that would work would be if each user had their own monitor app which just reflected results exposed from a single invisible app which actually did the work.
I get the same behavior if I start the TS task manually or if it launches on boot automatically.
"Run only when the user is logged on" won't do, as I need it to resume even if the server restarts in the middle of the night.
I had been launching the app with a little PS script, so I could send a notification if the app failed to launch at all, but there's no change if I have TS launch it directly.
I suppose the proper solution would be to write this as a service. I put some time into that, but I haven't done that before and couldn't get it running. If the consensus is that that would be a better approach, I'll give it another try.
Any ideas? Thanks!
If you set the task to "run only when user is logged in" then it will be visible for you if you uncheck the "hidden" box.
If you have the "Run whetever user is logged on or not" choice checked, then it will be hidden even if you uncheck the "hidden" box. The implementation of Task Scheduler doesn't allow you to run programs in the foreground if you aren't logged in.
To solve this you can create a user that does AutoAdminLogon and start the application with the Startup script. By doing it this way, you will make the server log in with this user on boot and start the program you want.
If you then want to check how it's going or so, you can login as that user or switch to that session.