I am recording a script on HTTP based protocol and I am saving a file, a pop up opens and saves a file (.doc) on my local computer,while replaying the script I want to check the downloaded file path...is there any method?
LoadRunner 9.52
You will not have a file on replay. Your download is coming in the context of the HTTP data flow. If you log the information for the request you can check the log, but this still will not be a file that you can open. Your best bet is to use web_reg_find() or web_reg_save_param() to check for the existence of both the file header and footer in your http download stream. You also may want to check the size of the previous download. Then at some logic like this (P-CODED)
If (
file_header_exists
&& file_footer_exists
&& file_size>some_minimum_number_of_bytes
)
then ( I_have_a_valid_downloaded_file )
Just inmagine what you would be doing to your local file system if you required that all of the files be written to the local file system during the performance test. Your local hard drive would become a bottleneck for your entire load generator.
You might also consider running a single GUI Virtual User (Based upon QuickTest Professional Technology stack) to check for the one file download for a single user as a functional check.
If you are still engaging in functional checks then you are likely testing too soon for performance, for if it does not work for one then it will never work for many.
Related
I have some .sh files, this file contains my ssh and scp details.
I would like to encrypt the ssh files, upon encryption It should be able to execute/run.
like the background.js ( attachment ) file is encrypted but still executing in the browser
Background:
There is a difference between obfuscation and encryption.
Obfuscation hides the data or makes it hard to read, but it is still theoretically possible to reverse this and get back the original source data.
Encryption actually uses cryptography to make it near-impossible to decrypt without a key.
I believe the image I'm looking at above is "obfuscated" and not "encrypted" based on the details that you've provided.
Answer:
If you're running this file on a machine and not in a browser, I'd recommend looking at compiling it into an executable which will compile it into bytecode. This will likely accomplish your original intent of hiding the source. Nexe is one tool for NodeJS that can do this.
If you're running this in the browser, then you can only really obfuscate it. Terser is a library for this in NodeJS
And lastly, a common pattern for hiding ssh details is to put them into environment variables and have a script reference the environment variables rather than actually putting the credentials in the code.
In JS, that would be process.env.PASSWORD
As my title says, is it possible? I am begginer at front-end and trying to teach myself reactJS right now. I learned some javascript before and I know it is impossible to read or write files with it. Mainly what I want to do is to get string from input and lets say write it into file.
Well the question is, where does that file live?
Node is able to write to files because the files exist on the server that node is running on.
React runs in browser so there is no shared file system to write to. You can read from a file because the contents of that file get bundled into the Javascript that gets served to the browser.
If you want to write to a file, you would need to send an API request from your browser / React to a server and have that server write to the file system.
Additionally, as pointed out by Huy Nguyen, it's possible to write to the clients file system from the browser but that is going to be private to that user.
Your question is a bit vague. In addition to what #Stretch0 said, it's possible to read/write files on a user's computer using the browser's native APIs. Here is a good tutorial.
I am mounting a folder as a virtual drive and i want to run a .exe file everytime user opens any file present in that folder. To be precise the folder would contain dummy files present on some other machine. By dummy files i mean the file would be listed but it would be a empty file. Whenever user opens a file i want the .exe program to download that file from another machine and display it to user.
That functionality (remote access on demand) can be implemented using reparse points and file system filters.
You could
use hooks to rewrite the jump address of OpenFile and in the
detour function check for the handle type, retrieve it's info by
using GetFileInformationByHandleEx, parse the data, download
what you need, open the downloaded file and then return
STATUS_SUCCESS or any appropriate error status in case one occurs.
Note
this is a bit more complicated as you also need a auto-inject
mechanism to inject function/library into each process according to
it's architecture.
this is not a safe procedure as most AV's will most likely consider your code malware.
Im want to build a file system for non-tecks( dont care about old versions of the file so no merging or svn/git). The thougt is that a user should be able to download a file, in the same instance the file should be locked for other users. When the first user is done editing the, the file should then automaticaly upload to the server. When he closes the file, the lock should den be opend.
Is this even possible? Im thingking a sort of browser plugin, but I cant find anywone that has done the same thing. (besides microsoft, but who want to go down that road)
That would be: Sharepoint, Alfresco, (almost every WIKI), ...
Actually that is a basic feature of most document management systems. Even SVN has that already and IIRC you can set that up with mod_dav_svn without a line of code (considering configuration is not code).
Also the interesting question is, IMHO, not TheHappyCase where the described unit of work goes well but what about this*:
I Checkout 50 random documents you need
(get some popcorn and wait for your stresslevel to go up)
?????
I get bored and forget about it (everything still being checked out)
*: Points (1) and (2) may change order
I am currently working on a file processing service that looks at a fileshare, where files are uploaded to via FTP.
For scalability I've been asked to make this service to be able to be load balanced, so the service has to expect that other services on different machines may also be trying to process these files.
OK, so I thought I should be able achieve this by obtaining an exclusive lock for my process before processing a file, and skipping any files that may already be locked by another process.
The crux of this approach is shown below (I've left out the error handling for simplicity):
using(FileStream fs = File.Open(myFile, FileMode.Open, FileAccess.ReadWrite, (FileShare.Read | FileShare.Delete))
{
//Do work
}
Q1: My process now has a lock on this file. I thought this would mean I could then access the same file (without using the stream) and still have the correct access to it, but based on testing it seems I only have the benefits of the lock through the stream. Is this correct?
(For example, before I included FileShare.Delete, File.Delete(myFile) failed)
The above lock ultimately uses the 'Write' permission to determine which service has the file, but is intended to allow other processes to still Read the file. This is because the process that has the lock attempts to verify if the file is a valid zip file , which uses a third party library (Xceed.Zip). However this fails saying the file "is being used by another process". Using reflector I ultimately found the problematic call is:
stream = this.m_info.Open(FileMode.Open, FileAccess.Read, FileShare.Read);
Now I would have expected this to work as it only wants to read the file, but it fails. The reason appears to be outlined in a similar question. However, as this is a 3rd party API I can't change their code to use ReadWrite.
Q2: Is there a way I can correctly lock the file so it will not be picked up by the other services, but it can still be verified as a zip file using the external API?
I feel like there should be a 'correct' way to do this, but at the moment the best I can come up with is to lock the file, move it away from the shared directory, and then verify it at the new location.
If you're planning to reactively handle this situation by handling UnauthorizedAccessException I think you're making a serious mistake.
This can be handled by proactively renaming files. For example you can configure your service to only read files whose name is in the format 'Filename.YYYYMMDD.txt'. Prior to processing the file, you can rename it to 'Filename.YYYYMMDD.processing'. Then after processing the file you rename it to 'Filename.YYYYMMDD.done'.
You can even take it a step further by making another service that enqueues the filenames. This service will be a FileSystemWatcher that listens for FileAdd operations. Once it receives that event it proceeds to queueing the Filename to a global message queue. Then, each of your service will just be dequeueing filenames and no longer have to worry about concurrent access.
HTH