We are getting an error in an application that I have written inside a corporate customer. the app is built in asp .net webforms. We think we are getting an error from Dragon. The error is: Conversion failed when converting the varchar value '{"protocol":"nuanria_messaging","type":"request","messageId":32,"action":"banejkelfpdmmmfobepfdnbmbbnecnol:activate","responseRequired":false}' to data type int. I don't have access to the two users that get this error, but both are dragon users and they have confirmed that both have the problem.
I think that there is a hidden field that I use to hold an integer. I think that dragon is overwriting the content in the hiddenfield, but I'm not 100% sure. The hiddenfield is the only integer that I have.
Is there any thought on how to stop dragon from interfering in the browser? I don't do support and don't have access to this user's desktop. they have told me that the browser extension in chrome is disabled. Any other ideas are appreciated.
TIA.
Related
I am not an expert, but not a rookie either. I'm using Asp.net webforms. I set up an error catching routine in global.asax to log the error info in an SQL table and redirect to a friendly error page. I began finding hundreds of exceptions per day with this in the query string "?id=-1%27". I use query strings for items and categories but only allow integers of 3 digits or less. Then I started geo-locating the IPs. The vast majority of them are from Russia and surrounding countries. So I started storing all of the IPs in a table. Is anyone else experiencing this and how best to handle it. I want to catch legitimate errors, but this is a major annoyance. Any input would be appreciated. I have Googled for 2 days and can't find anything related specifically to this issue.
The %27 is ASCII for the single quote (') and that is a red flag for someone trying to perform SQL injection via the query string to your application's data access layer logic.
I would be less concerned about where the attacks are coming from and more focused on techniques for protecting/processing your data before it is even attempted to be used by your data access layer and data storage (read: database).
Using parameterized SQL and data sanitation (read: white-listing allowable text for strings) is a great first step in combating these attacks.
UPDATE
It might be worth considering creating a custom exception for the invalid ID value being passed in as part of the query string. You can then test for the length being greater than three and throw that custom exception. Elsewhere you can catch/trap that custom exception type and do whatever you wish with that (read: potentially ignore that exception if it is becoming too large of annoyance). Please understand that I would never advocate ignoring exceptions (empty catch block), but merely stating that is possible to do such a "bad" thing.
This is a simple question... yet I have spent some time poking around online to no avail.
In ASP classic (which I am unfortunately stuck with), I need to know the range of possible values returned by getting session.sessionid. I can print it just fine but without a better idea of how it works (besides the obvious incrementation), I don't trust testing to determine it.
Any information/resources/leads at all would be appreciated. Thanks!
Session IDs are created bij the server. Thus, session.sessionid gives you the ID generated by the server.
session.sessionid always gives you a series of 9 digits. As you can read in the sources below, the Session ID is always generated the same way (32 bit long integer, which gets encrypted).
Take a look at this resource. The linked document in the article is an interesting read.
And another article.
We have a legacy setup that creates pdf's on the fly based on client info. I can follow everything through where the process gathers the info and everything runs normally, until it gets to the doc.Form.FlattenFormFields then it goes in to limbo. I've captured the base64binary string and it tried to use that to convert to a pdf with no luck also.
Anyone have any ideas or tips on pdf4net. I know this is a vague question but a lot of the system is a black box so we aren't even sure where to start.
OK figured out that the problem was corruption in the memory stream of the pdf. The process is using Strata frames (a black box) and passing in a doc ID and session parameters which are stored in a cookie. We had to change the cookie a week or so back because some clients session cookie was getting too big (he was storing a butt load of data in the cookie). We bypassed the Strata frames call that created the memory stream and are creating our own in .net and it is working in the test environment now.
I'm trying to understand exactly how the SessionPageStatePersister interacts with the web browser, ViewState, and SessionState. I've been under the impression that using a PageAdapter which specifies the SessionPageStatePersister (rather than HiddenFieldPageStatePersister) will store all of ViewState into SessionState.
After inspecting the SessionPageStatePersister in Reflector I'm starting to question this assumption. It appears that the SessionPageStatePersister.ControlState property is still stored in the RequestViewStateString (SessionPageStatePersister.ViewState is stored in SessionState), when viewing the SessionPageStatePersister's Save method.
Can anyone shed some light on this ControlState information isn't stored in SessionState as well? It seems that the only data that needs to be stored in the RequestViewStateString is the date stamp for the SessionState key: "__SESSIONVIEWSTATE" + Convert.ToString(DateTime.Now.Ticks, 16).
Yes, the control state stays on the page and rides up and down with the request/reponse by default. I agree that this seems pointless, but you can overcome this by add a flag to the browserCaps section in your web.config as mentioned in this article:
http://szokelizer.blogsome.com/2006/11/09/how-to-put-controlstate-into-viewstate-and-how-to-put-viewstate-into-session/
Check out the part toward the end for the info you need.
I suggested to the team that they turn this setting on by default. Maybe if you vote the issue up, they will! Here's the link for that:
http://aspnet.uservoice.com/forums/41202-asp-net-webforms/suggestions/2454872-make-httpcapabilitiesbase-requirescontrolstateinse
I'm a ASP.NET and ABAP developer. For years, I used RFC's to communicate with ASP.NET using SAP .NET Connector.
During the integrated tests, sometimes we need to debug a RFC that has been called from ASP.ENT, just because the bug we are facing does not happens at SE37.
So, everytime I needed to debug the RFC, I just inserted:
IF <<CONDITION>>. WHILE 1 EQ 1. BREAK-POINT. ENDWHILE. ENDIF.
By doing so, the program gets stuck. Then I go to SM50 and debug it.
I was wondering if there is any other way of doing this, because I don't like the idea of changing code in order to debug, or implementing some debug control functionality.
So, what do you do when you need to debug RFC's?
Thanks in advance!
I assume you are using a fairly recent version of sap (4.7+)
Do the following:
Get the username that makes the RFC call into SAP in ASP
Fire up SE37, go to the code section of your RFC
Look at the menu on top, click on 'Utilities'
Click on Settings
Go for the Debugging tab
Fill in the username that will make the call from ASP
Click IP Matching (otherwise a debug session appears for every time any user makes the call)
Session breakpoint active immediately is nice to click as well
Put your external breakpoint where you need it (click the icon with the stop sign and the little man)
Test your ASP connector
The breakpoint should come into effect, a debug window will pop up
You might not have the authorization to do this, if it doesnt work, use SU53 to find out what you're missing.
This should work.
Tricky .. can you elaborate what you mean by "the bug does not happen at se37"?
Does that mean that you cannot reproduce the data that leads to your problem or that the problem is specific to the fact that the function module is called via RFC?
Usually, you should be able to use se37 to start the function module, and there are some ways to record different data constellations to the function module. The behavior of the function module should be the same, regardles of being called from se37 or via RFC ...
When you call a RFM via SE37 you unknowingly use SAP selection screen.
In case you have a table with header-line
when invoked from RFC it might have header line "filled up"
In case you call same FM from RFC the header line in initial.
LOOP AT PT_JNC.
EXIT.
ENDLOOP.
or READ TABLE PT_JNC INDEX 1.
will help populate header line
This is a subtle difference.
Other simple differences are SAP uses YYYYMMDD date format and HH24MISS time
Regards
jnc at Kolkata