I have some solutions running on third-party systems, and every so often a customer specific error occurs. Unfortunately, due both to the amount of customer customization and the access difficulties, we are not really able to replicate these (rather trivial) errors. Is there a application, free or paid, that can easily run on a Windows server, record all activity and send back a video to our servers?
Related
I'm using Python and Plaid's development environment to download bank balances and transactions. To get the initial access tokens, I'm launching Link from quickstart, and can do that in standard and update mode.
The problem I'm running into is how frequently my API call returns the ITEM_LOGIN_REQUIRED error and I have to re-authenticate. For a Regions account I've been testing, this happens a few times throughout the day. For a Pinnacle Financial Partners bank, this happens almost immediately after updating the access token. As in, I can log in through link, successfully fire an auth/get request, and by the time I can send another request (e.g., balance/get), I'm already getting ITEM_LOGIN_REQUIRED again.
As I'm evaluating Plaid for production use, is this frequent authentication atypical? Is it a known limitation with development, or with specific banks even on production? I've seen some banks (Bank of America) only work in production, but I'm hoping what I'm experiencing is just the nature of working in development. Thanks.
Development vs. Production environments are virtually identical and shouldn't impact how often you hit ITEM_LOGIN_REQUIRED.
What you're seeing is atypical, though. Unless you have multi-factor auth turned on and configured not to trust known devices, this shouldn't happen.
Assuming you don't have that configured, would you mind submitting a support ticket so Plaid Support can look into this and help figure out why it's happening?
Can an Oracle APEX application be used to run scripts on the client side local (w7) PC?
I would like to be able to communicate with devices on the local PC, collect data and post it back up to the database. This is for the purpose of test automation which was previously done using MS VBA and MS access.
As with any other sort of web application, not easily. For good reason, web browsers generally do not allow web applications to execute random executables on the client machine. If they did, it would be a huge security hole that would allow an attacker to do whatever they want to your machine just because you visited a malicious web page.
Potentially, you could write (or find) an ActiveX control or a Java applet or some other sort of client-side control that could be given privileges to run scripts on the client machine. But that would probably require a pretty substantial amount of "futzing" with permissions that might make the machine vulnerable to malicious web sites.
Assuming that there are a relatively small number of client machines, you could also potentially install the Oracle Scheduler Agent on each of the machines that you want to execute scripts on and then use the Oracle Scheduler on the database to start jobs on the remote machines. If you did this, you could potentially start jobs on any of the client machines from an APEX interface.
I have a business LS web application which I update from time to time.
I do the update by simply using the deploy wizard and everything is working great.
My problem is handling all my users that opened my system in their IE and left it open through my deploy process.
Since they have the old web application is opened on their browsers, and I have deployed the new version to the server, I can see errors occuring in certain situations.
Is there a way to make sure all users with the application opened will be forced to refresh the web application page? Maybe remotely disconnect all currently connected users?
There is no built in way of doing this. You will need to write a custom solution. Someone in the MSDN Forums has written a class to do this for OOB apps.
You should be able to reuse the timer part of that class. I'm not sure if the UpdateAvailable method will work for Web-based applications or not. You'll have to experiment with that.
Alternatively, you can create a custom notification system. Insert a message to your users into a table in your database from the administrator account. Have a timer on the user account check the table every so often. If it finds a new message, display a notification to the user.
Then you can use either an HTTP Response Header or an ASP method to log the users out as described in this Microsoft Support article.
(Also asked over on ServerFault, where I was advised to post it here too)
We have a requirement to send desktop alerts to various users (compliance, production) across a network when other users have submitted content online for a report.
At present we are using NET SEND but this has no guarantee of delivery and has proved unreliable from both client and server perspective (and I gather will be unsupported in later versions of Windows; we are currently running XP).
We are considering a Jabber-based solution but has anyone used a Jabber client to pop up alert messages on the screen like NET SEND does, as opposed to just bringing a chat window to the front or displaying a temporary 'toast' message near the system tray.
We need the alert message to be persistent and only dismissed by the user, indicating they have seen it. Toast-style pop-ups would be fine as long as it was not only for a limited time and again had to be dismissed by the user.
Any solutions?
Openfire is a java based Jabber server that seems to be targeted to a corporate/business environment and provides the "toast" message feature with their Spark client. They also offer several other useful business-focused features.
Offline message delivery is not guaranteed by XMPP specification. It depends on concrete server implementation. Moreover, it has cost in supporting user accounts.
As an out-of-box solution it is fine, but since we are in development community, I would
consider building alert system using MessageQueue for guaranteed delivery.
The message-delivery semantics of XMPP are liable to be a good fit for your application, since you're not talking about financial transactions that require fiduciary-level delivery guarantees. It will certainly be better than NET SEND by a lot.
Write a simple client that listens for messages and does the pop-ups in whatever format you want, and have the program run in the background, perhaps with a tray icon. Writing something like that with Jabber-Net would be the work of a few hours, for example.
How can my app get a valid "last time connected to domain" timestamp from Windows, even when the app is running offline?
Background:
I am writing an application that is run on multiple client machines throughout my company. All of these client machines are on one of the AD domains implemented by my company. This application needs to take certain measures if the client machine has not communicated with the AD for a period of time.
An example might be that a machine running this app is stolen. After e.g. 4 weeks, the application refuses to work because it detects that the machine has not communicated with its AD domain for 4 weeks.
Note that this must not be tied to a user account because the app might be running as a Local Service account. It the computer-domain relationship that I'm interested in.
I have considered and rejected using WinNT://<domain>/<machine>$,user because it doesn't work while offline. Also, any LDAP://... lookups won't work while offline.
I have also considered and rejected scheduling this query on a dayly basis and storing the timestamp in the registry or a file. This solutions requires too much setup and coding. Besides this value simply MUST be stored locally by Windows.
I don't believe this value is stored on the client machine. It's stored in Active Directory, and you can get a list of inactive machines using the Dsquery tool.
The best option is to have your program do a simple test such as connection to a DC, and then store the timestamp of that action.
IMHO i dont think the client machine would store a timestamp of the last time it communicated with AD. This information is stored in active directory itself (ie. on the DC)
Once a user logs into say a Windows machine the credentials are cached. If that machine is disconnected from the network the credentials will last forever. You can turn this feature off with group policies, so that the machine does not cache any credentials.