how to handle download request from a WebView using WebResourceRequestFilter blackberry Cascades - qt

i want to handle any download request coming from Webview. how it is possible ? the documentation https://developer.blackberry.com/native/reference/cascades/bb__cascades__webresourcerequestfilter.html and https://developer.blackberry.com/native/reference/cascades/bb__cascades__webdownloadrequest.html are describing the parameters but couldn't figure out how to do it.

Your question is not clear on what you don't understand. Remember this is not a training forum, the idea is that you should try things, review the documentation and then ask specific questions to get the best out of a forum.
Moreover it is not clear whether you are trying to handle the download request at the Server, or capture the request before the download attempt leaves the BB.
I'm going to assume you want to display a web page on the BlackBerry but make sure that any resource requests that the page generates, are filtered by your program, so that you can supply the data (assuming you have it).
I implemented something like this a while ago and remember that it was not simple to figure out what was going on, but I played with it a bit and it all made sense.
I don't remember using WebDownloadRequest and can't really see how it helps in this case.
The key is WebResourceRequestFilter. You create your own WebResourceRequestFilter making sure you implement the required methods. Then you use WebPage::setNetworkResourceRequestFilter(WebResourceRequestFilter*) to make sure the webpage will ask your WebResourceRequestFilter for its resources. The first method the web page invokes is filterResourceRequest(), and the return from this invocation determines which other methods in your WebResourceRequestFilter, the Webage will invoke.
I suggest you implement a WebResourceRequestFilter, put some debugging in filterResourceRequest(), but always return FilterAction Accept, which means the web page will use its normal processing to obtain the resources. Then try various other FilterAction return values and see what happens...

Related

User Identity Info

I've been messing around with creating my own implementation of an AspNet.Security.OAuthProviders by copying the GitHub example. Have a few questions..
First, I successfully authenticate but when I get back my User.Identity.Name is empty. I don't see that information coming back from my provider. Noob question I imagine, but do I have to explicitly request the information I want back? If so, how do I know what to ask for.. I'm kind of working blindly.
Second, in the GitHub example of the Handler, CreateTicketAsync immediately makes a call to the UserInformationEndpoint. In my use case, after getting authorized I want to go to a page that has some links to some api requests that will use the acquired authorization, rather than do it right away. I'm not sure if there is an example for that or I'm making incorrect assumptions and going about this the wrong way.
This is entirely supposed to be for demo purposes as a "how to" for other developers so I want to make sure I do things the correct way.

Check if URL targets Action (vs. file/etc)

I'm trying to determine the best way to determine if a URL (as seen in the global.asax) is for an action. I'm wanting to exclude EVERYTHING else...i.e. a request to a bundle would fail as well as a request for a file.
It seems clunky and dirty to check to make sure the request isn't for a file/directory/bundle/etc. I'm hoping to be able to instead JUST check to see if it's an action, but I'm having issues coming up with what that test would look like.
Just FYI, in case it's relevant. I'm working on some internationalization of a site and I'm needing to filter the Request objects so that I only fiddle with the one for the initial request.

Google Geocoding Recommendation

I am looking into utilizing Google Maps API to do some geocoding. I want to implement client side geocoding, to remove the possibility of request limitation.
I need to do some fairly complex logic on the result set, and I would prefer to do that in C# as it is a ASP.NET MVC application. However part of that logic is possibly makeing subsequent follow up requests and that again would require JavaScript.
So, my first thought is to make a service in my application to pass JSON results to and certain return types to trigger the subsequent request. That seems a little convoluted and want to know from the community if this seems like the best approach and if there are any libraries/third party tools that can help handle this situation.
I've an app that does something similar, with the complexity somewhat decoupled by using standardized events (within this app, not a W3 standard or anything)
Client uses native geolocation, SimpleGeo and Google Loader to guess where the user is and AJAX's that to the server.
Server uses client data, MaxMind, and user preferences to decide where to treat the user as being.
Server response is generic event data (as JSON response) that is converted by a generic AJAX response handler into one or more events triggered against the body element.
Depending on the page, various listeners are bound to the events and or namespaces (see jQuery namespaced events) and they handle the updated location events, e.g., getting different weather data, changing local search results
Some of those listeners in turn trigger other AJAX requests, the responses to those may also carry generic events to triggered...
This way there's no sequential code I have to write, i.e., I can add or remove behaviors (simple or complex) without changing anything else. jQuery Events are all I use, really nothing much to it after you decide how you'll pattern things.
Let me know if that's interesting to you and you want me to expand or clarify a part of it.
You may want to try this API:
http://code.google.com/apis/maps/documentation/geocoding/
It's far more REST like - no Javascript required. May work better with C#
In the end I found the best solution was to do as I stated in my question. Pass the JSON object to controller, do work, then return. Worked pretty well.

Filtering Data in ASP.NET Web Services

I've been using this site for quite a while, usually being able to sort out my questions by browsing through the questions and following tags. However, I've recently come across a question that is rather hard to lookup amongst the great number of questions asked - a question I hope some of you might be able to share your opinion on.
As my problem is a bit hard to fit into a single line, going in the title, I'll try to give a bit more details on the problem I've encountered. So, as the title says I need to filter, or limit, some of the response data my standard ASP.NET Soap-based Web service returns on invoking various web methods. The web service is used to return data used by other systems (a data repository more or less), where the client today is able to specify a few parameters on how the data should be filtered and in return a full-set of data back.
Well, easy enough I thought, just put additional filtering options on the existing web methods which needs a bit more filtered applied, make adjustments on the server-side and we are all set to go - well, unfortunately it turned out to be a bit more tricky then this.
The problem I am facing is that I'm working on a web service running in a production environment, which needs to be extended in such that additional filters can be applied to existing web method being invoked w/o affecting the calls already being made by other systems used by the customer using their client stubs. This is where I am a bit troubled, since I can't seem to find a "right solution" on extending the current web service.
Today, the filter is send as a custom data structure which holds information on which data should filtered, but I am not sure if I can simply just add more information to this data structure w/o breaking code at the clients? One of my co-workers suggested that I could implement a solution where I would extend the web.config on the server-side to hold a section with details on which data should be excluded (filtered out), but I don't find this to be a viable solution long-sighted - and I don't trust customers with such an option since this is likely to go wrong at some point. So the solution I am looking for is a way that I can apply a "second filter" to the data I am requesting from the client so instead of getting a full-set of data back it should only give a fraction, it implemented in such that the filter can be easily modified and it must not affect the current client calls.
Any suggestions on how I should approach this problem?
Thanks!
Kind regards,
E.
A pretty common practice is to create another instance of the application OR use part of the url to signify the version of the endpoint they are connecting to, perhaps the virtual directory is the date. That way old calls will go to the old API and new calls will come in on the new API.
http://api.example.com/dostuff
vs
http://api.example.com/6-7-2011/dostuff

So why should we use POST instead of GET for posting data? [duplicate]

This question already has answers here:
Closed 13 years ago.
Possible Duplicates:
How should I choose between GET and POST methods in HTML forms?
When do you use POST and when do you use GET?
Obviously, you should. But apart from doing so to fulfil the HTTP protocol, are there any reasons to do so? Less overhead? Some kind of security thing?
because GET must not alter the state of the server by definition.
see RFC2616 9.1.1 Safe Methods:
9.1.1 Safe Methods
Implementors should be aware that the
software represents the user in their
interactions over the Internet, and
should be careful to allow the user to
be aware of any actions they might
take which may have an unexpected
significance to themselves or others.
In particular, the convention has been
established that the GET and HEAD
methods SHOULD NOT have the
significance of taking an action other
than retrieval. These methods ought to
be considered "safe". This allows user
agents to represent other methods,
such as POST, PUT and DELETE, in a
special way, so that the user is made
aware of the fact that a possibly
unsafe action is being requested.
If you use GET to alter the state of the server then a search engine bot or some link prefetching extension in a web browser can wreak havoc on your site and (for example) delete all user data just by following links to your site.
There is a nice paper by the W3C about this: URIs, Addressability, and the use of HTTP GET and POST.
1.3 Quick Checklist for Choosing HTTP GET or POST
Use GET if:
The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).
Use POST if:
The interaction is more like an order, or
The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or
The user be held accountable for the results of the interaction
Because, if you use GET to alter state, Google can delete your stuff.
When do you use POST and when do you use GET?
How should I choose between GET and POST methods in HTML forms?
If you accept GETs to perform write operations then a malicious hacker could inject somewhere links to perform an unauthorized operation. Your user clicks on a link - and something is deleted from a database. Or maybe some amount of money is transferred away from the user's account if he's still logged in to their online banking.
http://superbank.com/TransferMoney?amount=1000&recipient=2342524
Send a malicious email with an embedded image referencing this link, and as soon as the document is opened, something funny has happened behind the scenes.
GET is limited by the length of URL the browser/server can handle. This used to be as short as 256 characters.
There is atleast one situation where you want a GET to change data on the server. That is when a GET returns data, and you need to record which data was given to a user and when it was given.
If you use complex data types then it must be in a POST it cannot be in a GET. For example testing a WCF web service in a browser can only be done when the contract uses simple data types.
Using GET and POST where it is expected helps to keep your program understandable.
When you use POST, you can see the information being "posted" in the address-bar of the web browser. This is [apparently] not the case when you use the GET method.
This article was somewhere on http://www.w3schools.com/ Once I've found the exact page it was on, I'll repost. :-)

Resources