The document Fetch document states
A request has an associated client (null or an environment settings
object).
What does it mean for a request's client to be null?
For example, if I run a wget at the command line, is the client for that request null? If I type in a URL in my browser's URL bar and hit ENTER, what is that request's client?
That's a good question. Section 5.2 of draft-ietf-httpbis-rfc6265bis-05 provides some answers. It describes one case in which a request's client is "null".
If "request"'s client is "null", return "same-site".
Note that this is the case for navigation triggered by the user
directly (e.g. by typing directly into a user agent's address
bar).
Whether this is the only case in which a request's client is "null" is unclear to me, though.
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'm currently developing an App using Microsoft LIVE 2.0 API
Currently, I’m using these URLs as my authentication endpoints:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token
However, when I sent the request to the token endpoint with the redirect URL as
https://blabla.com/accept_token.php?api_ver=wave5&csrf=AY7F6O4hF0n8yW3i2O_y6N-ky7zzfULiYV_fttLK1S3JgaeQz2GTk9FOeIGBBH5CvkfkEYCyPOCQCujcrij4KDy2wAMZyXqx24jvwZRtzOv0s9ADGYl1iFtvYtkmgeFmZEY&appdata=%7B%22use_case%22%3A1%2C%22type%22%3A1%2C%22flow%22%3A2%2C%22domain_id%22%3A12%2C%22tracked_params%22%3A%22%5B%5D%22%7D
I got errors saying the reply address does not match the reply addresses configured for the application
For the application, I set the reply address to be https://blabla.com/accept_token.php.
Is it possible that I add some parameters to the url and still make it match?
I'm pretty sure the reply url you send must match exactly the reply url registered on the application, including any query strings.
If there is variable state informaiton you need passed throughout the authentication process, you should use the state variable.
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oauth-code
state
A value included in the request that will also be returned in the token response. It can be a string of any content that you wish. A randomly generated unique value is typically used for preventing cross-site request forgery attacks. The state is also used to encode information about the user's state in the app before the authentication request occurred, such as the page or view they were on.
I deployed a weather app created with create-react-app. In development I would use the chrome extension allow access control origin. Now that it is deployed with github pages, I'm getting the error:
No 'Access-Control-Allow-Origin' header is present on the requested
resource. Origin 'https://boka44.github.io' is therefore not allowed
access. If an opaque response serves your needs, set the request's
mode to 'no-cors' to fetch the resource with CORS disabled.
It seems like I need to add a header to my server, but I'm confused as to how and where to add it.
My code is here: https://github.com/Boka44/weather
Any help would be deeply appreciated.
The API endpoint (The one that provides weather information) which you are calling has disabled CORS which means you can never make a client-facing call (i.e. through a browser) because the browser will block the call.
You have 2 options here:
If you can change the API endpoint: you can add a CORS header to allow origins from your client app's domain.
If you cannot change the server code: Create your own API endpoint that calls the original API endpoint and have your client app call your own API. (i.e. You just make a proxy server that directs your calls to the original API endpoint). In this case, you can specify a CORS header on your server to allow calls from your client app domain only.
Dark Sky API docs says that it is not allowing CORS. So you can't get data to your client side code from their server. So create a proxy server in PHP or some other platforms, which will make an api call and produces the JSON formatted response.
I'm learning reactjs, redux and json web token. I'm new on all of them.
In my sample application user sends information from a login page. If the information is true jwt is created and it is set in the state and sent to the client side. It is set to the localStorage. When an other request is sent from client, token in the localStorage is sent to the server via redux action for verifying.
I read some samples and tutorials. Some of them have sent jwt in the HTTP header.
Do I have to sent it to the header ? Are localStorage and state enough ?
Do I have to sent it to the header?
You must send it to the server in a request somehow. Whether that is as a header or as part of the request's payload, it doesn't matter, however it is more convenient and almost certainly considered better practice to send it as part of the Authorization header. Using the Authorization header will allow you to avoid moving the JWT between a request's body and query parameters depending on its type (POST / GET etc.).
Are localStorage and state enough?
No. Storing the JWT locally on the client does not inform the server of the client's authenticated state. You must send the JWT to the server with each request that requires user authorisation.
Do some reading around JWT. There are plenty of links and libraries available to you online. Here is one to get you started.
i am using node/express server and angularjs as frontend. server sets the cookie and is shown correctly in the network response. but the cookie is not shown in the resource tab in the chrome developer tools. What are the possible reasons for the same.
Below are 2 potential reasons for not actually setting a valid cookie:
Invalid expiration time - the cookie expires at a time in the past from the browser's perspective
Invalid domain for the cookie. Let's say you serve the page from example.com, but your server tries to set the cookie for domain google.com
There could also be a bug in the chrome dev tools to not show your cookies, but you can check that easily by issuing another request to the server and see what cookies are actually received by the server.
It might be that your cookie is the HTTPOnly authentication cookie. Those are not shown in chrome unless you're browsing the localhost.
If you're certain that the cookie is set and is being sent to the server, but you cannot always see it in the cookies pane in the developer tools, check that both the host and the path match the current URL in the browser. One option which may not always be suitable, is to explicitly set Path=/ in the cookie, to match all URLs.
Details
When you're browsing your site with the developer console open, the cookies pane will show only the cookies that match the current host and path in the URL. For example, if you set your cookie for subdomain.example.com but are currently at example.com, the cookie for subdomain.example.com will not appear, even if it is currently set. Navigate to subdomain.example.com and you should now see it in the console.
Likewise, say your Node application at example.com/api did not set the Path in the cookie and it was automatically set to Path=/api. This will only be visible on the console, when and if you browse to a page that starts with example.com/api/. Your JavaScript code in the same page, sending requests to example.com/api will naturally include this cookie, even though it's not visible on the console, due to the path in the URL being different.
You can see the domain and path for all cookies on the site information pop-up. This is typically done by clicking the icon to the left of the URL, e.g. a padlock if it's HTTPS. Under the cookies section, you can see a box like the picture below for Opera, similar to other browsers.
Note the path and domain for the selected cookie.
Potential Solution
Explicitly set Path=/ in the cookie. According to the Set-Cookie MDN documentation for Path=<path-value>:
Indicates the path that must exist in the requested URL for the
browser to send the Cookie header.
The forward slash (/) character is interpreted as a directory
separator, and subdirectories are matched as well. For example, for
Path=/docs,
the request paths /docs, /docs/, /docs/Web/, and /docs/Web/HTTP will all match.
the request paths /, /docsets, /fr/docs will not match.
What is implicit in the above quote, is that using Path=/ will match all URLs in the given domain. Before taking this approach, you should be certain that it suits all scenarios in your particular use cases.