Since I know Cypress, I offered to help a friend screen scrape data out of a legacy system for which he no longer has database access, but I seem to be at a dead-end.
The PHP code fills the form fields somehow, and I can cut'n paste from them into an editor but, when I try to automate that, the input field's innerText is always empty strings. I can use Dev Tools to search the DOM and find the text of the field labels, but searching for the input field text turns up nothing.
Is there really no way to get at that data?
How can Chrome be unable to find data that it is actually displaying?
Is this some kind of security barrier?
Related
Is there a possibility to searching inside all JSON objects from all available responses in the network tab? Currently it works, but very randomly and isn't much reliable. Sometimes and especially in a smaller responses it's ok but when you have more assets almost always looking for, e.g. specific params value ends unsuccessfully. Do you know any smart solution of that issue? I've checked and first question associated with it has already few years and Google devs still haven't responded.
Example: I have object ID in response body, but cannot find it by search CTRL+F
I think one way is to save all the response in a file (manually or automatically, if possibile by using a browser extension).
After you have stored all the responses in a file you can parse the file and find things inside the file by using a script or just regex.
You can save the answers (as HAR file) manually (I use firefox) by right clicking on a network response inside the developer console panel.
I found that is the same for chrome.
Look here:
https://developers.google.com/web/tools/chrome-devtools/network/reference
I didn't search if there is a way to automatically store all the responses received by a browser. I'm not sure, but I think it isn't possible :/
Filemaker Pro 14.0 with Google Chrome and Safari both did not seem to work with WebDirect. The code concerned is:
So this works fine in filemaker client and I get a http request logged on my http server and a proper response is received. Webdirect somehow does not like it and I get no response, nor do I get a hit on my http server. What is even strange is that, it does not even show the current record from the database (the first record, which was selected on line 3).
My best guess is I am doing something which is not supported by WebDirect but fail to understand what exactly.
Basically what I am trying to do, is make a http request and retrieve the response text into a FileMaker variable. I am doing this by saving the response in a column and then retrieving the value of the column in a variable.
PS: Can someone also point me out how I can copy text from the scripting window?
I'm afraid there's much that seems wrong with the script. Perhaps you mistyped it, not having the ability to copy and paste the script?
Show Custom Dialog can't directly set the value of a variable. You need to use the input fields to set the value of a field, usually a global field, and you can then use that directly or you can move that value to a variable.
You don't seem to be setting the http_wrapper_response::response field to any value. The way you have that written, it will actually clear any value it may have.
The third line doesn't set the current record, it sets the text selection to the contents of that field, which you're clearing in the line above.
Can anyone point me to info about how to create a Microsoft Word document that changes text input fields depending on what the user selects in a drop-down menu?
I'm using Word, Developer toolbar, Design mode, and have gotten as far as how to create the drop down selection box, and add text input fields below that on the page, but I need to know how to change what fields appear depending on what the selection is. I'm sure it's possible, I just don't know how to go about it.
I'm pretty good with this sort of thing in HTML with javascript and jQuery, but Word is its own little world.
I tried the "structured" tab but it suggests selecting XML add ins, and none appear in the list to select.
One option is using a template approach in combination with 3rd party toolkit and external application. External application takes care for user interface where user selects template and sets filter for data retrieval. The application then reads the data, generates new document based on template and populates it with data.
You don’t have to mess with MS Word macros and this solution can survive Office upgrades very smoothly.
Template design in done in MS Word. We are using third party toolkit (i.e. Docentric Toolkit) for populating Word documents with data.
for my company I am making a report in Xi3/Desktop Intelligence that pulls data via free hand SQL and makes a html file displaying the data, updating every 20mins. We want to incorporate a hit counter that will show us the number of times this report is being viewed.
I found a couple basic templates online. I tried copying and pasting them into a cell, but the output HTML page just displayed the full HTML (unrendered by my browser). I am decent at writing my own HTML, but I just do not understand how to stick my own HTML code in a dynamically updating report in Xi3.
Moreover, I doubt (for legality reasons) my company will be okay with me using a free hit counter template I find online, especially considering they all seem to reference a third party website to do the actual "counting." Any ideas of the best way to implement/learn how to create a visitor counter?
Thanks.
You can include HTML in a DeskI report. In the cell that contains the HTML, click Format Cell; on the "Number" tab, there is a checkbox for "Read as HTML". Make sure that's checked off. Note that you won't see the rendered HTML within DeskI, but it will display when viewed in Infoview.
I have a great concern in deploying the TinyMCE editor on a website. Looking at the code parsed by the editor it does a great job, and I leave the HTML button off the toolbar configuration so users can not inject their own source.
However, from what I read in the TinyMCE docs, it claims to degrade nicely to a regular textarea should javascript be disabled on a users browser... and therein lies my concern. If it does revert to a normal textarea, then the user is then able to easily inject their own HTML, and this leaves me with a security concern.
I just pass through data created with TinyMCE, and it is used within another page created by my script, so it poses no security risk to my server. The security concern arises over what malicious data may be passed to another user viewing the generated page.
I know many of you will tell me to just use regexes, or parse this data, but that itself could be a nightmare, as I would be trying to either...
a.) Use regexes to try and clean up the HTML without breaking the generated page,
and it is better to parse the data for that anyway.
b.) Reparsing data that has already been parsed by the RTF editor, which also
would probably end up breaking the generated page.
Anyone with any previous experience with this type of scenario, I would really appreciate a 'heads-up' as to any other risks that using an RTF editor for user data could entail.
I would really like to provide this as a user option, but not if the risks outweigh giving the user using the RTF a chance to take a wack at another user viewing the page that is generated by the script.
My gut feeling is to steer a wide berth around use of the RTF at this point.
Thanks for any direction you can give me with your own experiences.
You cannot have client-side security on the web. You simply can't trust the browser, because it's easy for a malicious user to substitute a replacement browser that does whatever he wants.
If you accept HTML from users (using TinyMCE or through any other method) and display it to other users, you must sanitize or validate the HTML in some way on the server. If you're using Perl, the leading package seems to be HTML::Scrubber (along with various other modules that help you plug it in to various frameworks). I haven't had occasion to try it myself.
The TinyMCE Security page mentions some ways to make it harder for people to submit arbitrary HTML, but you still need server-side checks.
Regex is generally not considered good for parsing HTML
RegEx match open tags except XHTML self-contained tags but I have noted the "perl" tag :)
My advice when taking markup from users is to always parse it through something that can accept mal-formed HTML and return well formed HTML. These parses generally produce something that can be queried and updated with some form of XPath.
In Python there is a module called BeautifulSoup, Ruby has Nokogiri and in ASP.NET there is a project called HtmlAgilityPack that all do this sort of thing. I'm not sure what library perl has, but I'm sure there would be something.