This may seem silly but I can't find the request timestamp in ServiceStack. I'm looking for the ServiceStack equivalent of
this.Request.RequestContext.HttpContext.Timestamp
in ASP.NET MVC.
I looked at the request headers but there's nothing there that resembles this.
In an ASP.NET host you can just get it off the HttpContext singleton, i.e:
HttpContext.Current.Timestamp
Otherwise if you didn't want to use a singleton you could travel down the Request object graph, i.e:
var aspnetRequest = (HttpRequest)base.Request.OriginalRequest;
aspnetRequest.RequestContext.HttpContext.Timestamp
Related
I am sending some perameters to the third party application using rest api In one of the perameter I am sending A URL, This URL will use by third party application to send a json response after 5 or 10 min. My question is how may i create that URL for third party app that they will use to send the response.
If the 3rd party can send HTTP headers too you could send to them the current user's session id. If that user is API enabled (checkbox in profile/permission set) - you could write an Apex REST service that accepts POSTs. They'd call it with Authorization: Bearer <session id here> and it could work very nice. This trailhead might be a good start for you. (or can you contact their developers and maybe agree to make a dedicated user in SF for them so they'd log in under their own credentials and send it back?)
If they cannot send any special headers (it'd have to be unauthenticated connection to SF) - maybe you could make a Visualforce page, expose it as Site and then page's controller can do whatever you need. Maybe you already have something public facing (community?), maybe it'd be totally new... Check https://developer.salesforce.com/docs/atlas.en-us.206.0.salesforce_platform_portal_implementation_guide.meta/salesforce_platform_portal_implementation_guide/sites_overview.htm
If none of these work for you - does the url have to ping back to Salesforce. Maybe you have control over another server that can accept unauthenticated requests like that and have that one then call SF. Bit like a proxy. You could even set something up fairly easily on Heroku.
Last but not least. This would be extremely stupid but if all else fails - in a sandbox enable Web-to-Case or Web-to-Lead and experiment with these. At the end of the day they give you an url you can POST to and pass a form with data. I think it'd have to be Content-Type: application/x-www-form-urlencoded and if you mentioned JSON they're likely to send it as application/json so might not work. If it works - you could maybe save the payload in Description field of Cases (special record type maybe?) and do something with it. I'm seriously not a fan of this.
I have an Apache camel application which talks with a web service. This is purely a integration(mediation) application. We take REST request and transform it to a SOAP message (using VM templates) and call the web service. Receive response from web service, transform it to JSON and send back to our client.
REST ---->transform to SOAP req (Velocity template) ---->call WS ---->receive response---->transform into JSON---->return response to caller.
We are using servlet endpoint to receive request from our client. We can obtain HttpSession object from exchange before calling web service as follows :
HttpServletRequest req = exchange.getIn().getBody(HttpServletRequest.class);
HttpSession session = req.getSession();
However, the problem is that I cannot obtain HTTPSession from exchange after receiving response from web service. If I check the Exchange object in debug mode, the Exchange.getIn() is of type DefaultMessage rather than HttpMessage. That is the reason I think I loose Request and response objects.
I tried setting the exchange pattern to InOut but that doesn’t help.
The only solution I could find is to store the original body of the in message in a header or a property and retrieve it at the end. But I think there must be a better solution that this.
Could anybody help please?
Note: We need HttpSession so that we can store corresponding session information like session id created on WS for the session created by our request. We cannot pass session information created on WS to our callers, and need a place on our application to hold this mapping info. HttpSession serves this requirement. Is there any better way?
You can store the http session as an exchange property, camel copy these properties across the exchanges, so you can access it in the route when you need.
I'm using BreezeJS 1.5.1 in an Angular 1.3 project to try to query a SAP Gateway server, which I'm assured implements OData. As the title says, every request to the $metadata service returns a 406 Not Acceptable response from the server.
<error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
<code>005056A509B11ED19BEB6513AA349DA5</code>
<message xml:lang="en">
The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request
</message>
</error>
I've tried initializing Breeze with several different adapter configurations ('OData', 'odata', 'WebApiOData'); this ensures that Breeze calls /$metadata on startup and not /Metadata, but does not fix the problem.
// breeze.config.initializeAdapterInstances({ dataService: 'OData' });
// breeze.config.initializeAdapterInstance('dataService', 'odata', true);
breeze.config.initializeAdapterInstances({ dataService: 'webapiodata' });
The Gateway server must always return XML for its metadata call (JSON metadata isn't available on SAP), and is having trouble with the Accept header of the request (Accept:application/json;odata.metadata=full). I can't find the right combination of headers that it will accept in Postman, other than those from calling the metadata service directly from Chrome (Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8) which works.
I've pointed the app at different services and even different Gateway instances, all with the same result. Have I missed a fundamental piece of config?
Edit 31/10/14
Per Ward's answer below, I intercepted the dataJS request (as suggested in the OData Ajax section at http://www.getbreezenow.com/documentation/controlling-ajax) and replaced the Accept headers for the $metadata call.
var oldClient = $window.OData.defaultHttpClient;
var myClient = {
request: function (request, success, error) {
$log.log('Intercepting OData request', request.requestUri);
if (endsWith(request.requestUri, '$metadata')) {
request.headers.Accept = 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8';
}
return oldClient.request(request, success, error);
}
};
$window.OData.defaultHttpClient = myClient;
Of course there's a different problem now but this one is solved at least.
No, you haven't missed anything fundamental. However, SAP may have.
As I recall, the result of an OData $metadata request is always XML, never JSON, and I believe that Breeze would have been happy to receive it as XML.
Yes, the accept header does specify JSON even though the response won't be JSON. That's kind of sloppy on the part of Breeze (or the Data.js library Breeze delegates to ... not sure yet).
But SAP should NOT have freaked out. The request's accept header is supposed to be advisory and the server should do the best it can to satisfy the request media-type format. It doesn't have to honor the requested format. In can return in a different format if need be.
In this case, SAP should have just sent the metadata in XML. Apparently SAP is being persnickety.
I'll look into this soon. Meanwhile, you can use a $http interceptor to patch the accept header yourself for this particular request.
Back with more later.
fyi, in SAP Gateway you can easily specify JSON or XML rendering via ...?$format=json or ...?$format=xml.
Default is xml.
So for metadata it would look like this:
...IWBEP/GWDEMO/ProductCollection/?$metadata&$format=json or ...IWBEP/GWDEMO/ProductCollectio/?$metadata&$format=xml
I have an angularJS application whose authentication system is made with an access_token and communicating with a backend server written in Go
Therefore to authenticate the user, I have to add the access_token to each request ?access_token=SomeTokenHere or via a header Access-Token: SomeTokenHere
It works great.
The issue is that my backend serves protected images, and I cannot put the access token in the image src for some security reasons(If the user copy/paste the link to someone else, the access_token would be given too ...)
What I'd like to do is to inject a header containing my access token, but since the request is made from the browser it doesn't possible.
This could probably be possible with a cookie, but I'd to avoid using a cookie especially because the angularApp and the backend are not on the same sub-domain.
Another idea would be to create a directive that would get the raw data, and set the data to the image. First I don't know if this is possible and is it a good idea for hundreds of images in the webpage ?
If you have any idea, I'd be glad to hear from you !
Thanks
It is typical problem, and fortunately it was already solved - for example on Amazon S3.
Solution idea is simple: instead of directly using secret key - you can generate signature with access policy, using that key.
There is good algorithm designed especially to generate signatures for this purpose - HMAC
You can have one secret key on your server and use it to sign every image URL before it would be sent to client, also you can add some additional policies like url expiration time...
I have a REST service sitting at http://restservice.net. I am implementing a client for this service in backbone. The client is simply an html file (for bootstrapping the application) and bunch of js files holding my backbonejs code. I am hosting these files on another site http://client.net.
My backbonejs code is calling into http://restservice.net but now allowed due to same origin policy. I have already looked at other SO questions that talk about how I can only talk to http://client.net.
Do I have to redirect every request through http://client.net. I see that as inefficient. What's the point in using a client side MVC framework then? Am I missing something here?
You have two options: JSONP and CORS both of these demand that your http://restservice.net server is setup to suppor the protocols. Forcing backbone to use JSONP simply requires you passing an option to Backbone.sync. One way to do this is like this:
sync: function(method, model, options){
options.dataType = "jsonp";
return Backbone.sync(method, model, options);
}
The problem with JSONP is that you can only make GET requests, so your REST api is effectively read only. To get CORS working you simply need to configure your api server to send back the proper headers . This would pretty liberal:
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, GET, PUT, DELETE OPTIONS
here is a pretty good run down on CORS. If you set that up, then things will pretty much work as usual.
If you don't have the ability to make changes to the server at http://restservice.net then you have no choice but to proxy all the requests to that service. This is definately inefficient but implementing is probably simpler than you would expect. One thing to consider is a reverse proxy