When I check the cookies on the server side (Classic ASP) as in the code below, the cookie with ASPSESSIONID does not appear.
<%
For Each Name In Request.Cookies
response.write (request.cookies(Name) & "<br>")
Next
%>
But when I take a log as below with JavaScript, there are several cookies starting with ASPSESSIONID.
<script>
console.log (document.cookie)
</script>
Q1) Why can't it be checked on the server and can only be checked through JavaScript?
Q2) At first, there was 1 cookie starting with ASPSESSIONID, and then it increases to 7-8. How much does it increase?
Q3) Can the administrator delete cookies starting with ASPSESSIONID?
Q4) Will cookies starting with ASPSESSIONID be reflected in the browser's cookie limit?
(I'm a little worried about this if it's reflected)
Related
I am using a chat widget from "tawk.to". It is giving a javascript way to append the chat widget in the html page.
The javascript way is
<script type="text/javascript">
var Tawk_API=Tawk_API||{}, Tawk_LoadStart=new Date();
(function(){
var s1=document.createElement("script"),s0=document.getElementsByTagName("script")[0];
s1.async=true;
s1.src='**** link to account ***';
s1.charset='UTF-8';
s1.setAttribute('crossorigin','*');
s0.parentNode.insertBefore(s1,s0);
})();
</script>
Now it is blocked by chrome by showing a warning as below:
A cookie associated with a cross-site resource at http://tawk.to/ was
set without the SameSite attribute. It has been blocked, as Chrome
now only delivers cookies with cross-site requests if they are set
with SameSite=None and Secure. You can review cookies in developer
tools under Application>Storage>Cookies and see more details at
https://www.chromestatus.com/feature/5088147346030592 and
https://www.chromestatus.com/feature/5633521622188032.
Any idea about the issue ??
I have been getting sporadic CSRF errors in an app that is mostly working ok. I do everything as I'm supposed to do: I use {% csrf_token %} in my template for normal forms and in my ajax POSTs I set the X-CSRFToken header:
$.ajaxSetup({
beforeSend: function(xhr, settings) {
xhr.setRequestHeader("X-CSRFToken", $.cookie('csrftoken'));
},
});
I'm even forcing the cookie to be set in all views by writing a custom Middleware that calls get_token
def CSRFForceCookieMiddleware(get_response):
def middleware(request):
response = get_response(request)
get_token(request) # Force to set cookie in all responses
return response
return middleware
Everything works OK in my localhost and in production for most users. But for some users I get 403 CSRF validation error.
I added a lot of debug info. Turns out that even if CsrfViewMiddleware is setting the csrftoken is setting the cookie in the response, in the actual browser the cookie is not set ($.cookie('csrftoken') is null). So when the ajax call is made, there is no cookie present in the request.
So, I guess this pretty much means that some users' browsers are blocking this cookie? Anyone else had this experience?
Most browsers have an option to "block all cookies". You may want to detect that in javascript and give your users a warning that some functional cookies are required for the site to work correctly. There's another SO question that shows how to do that.
Alternatively, grab the token from a hidden input field ({% csrf_token %} will add that field in your template). That should always work.
I have a Django app with about a dozen views that I am currently hosting on Heroku. I can do POST requests just fine to the app when directly going to the app url, and I have the 'django.middleware.csrf.CsrfViewMiddleware' enabled. I am running Django 2.1
I am currently having an issue where I am trying to embed this Django app within an iframe, on another site that I host on Weebly. I always get a 403 error when trying to do a post on any of the Django forms. The reason is "CSRF cookie not set."
I am doing this through Chrome on Ubuntu. I checked the Applications tab in the Developer console, and do see the csrftoken key-value pair set in the cookie for the Heroku domain. The Weebly domain does not contain the csrftoken key-value pair. I figured it would just use the cookie from the Heroku app domain and use the csrftoken, but that doesn't appear to be the case.
In Django, here are my settings regarding CSRF:
CSRF_COOKIE_SECURE = False
CSRF_TRUSTED_ORIGINS = ['example123.herokuapp.com',
'app123.weebly.com']
I REALLY don't want to disable security or use the csrf_exempt decorator, as that feels like a hack. I am pulling my hair out on this one!
EDIT:
{% csrf_token %} is in the form, and I can see the hidden field "csrfmiddlewaretoken":
<input type="hidden" name="csrfmiddlewaretoken" value="XXXXXXXXXXXXXXXXXXXXXXywkFTfTC9ttYiOTD0O8uF49SvRjaUWgWeLU0h2PjP2">
There are two different things with csrf in django
1. Csrfmiddlewaretoken : {% csrf_token %}
example of set-token header
2. CSRFcookie : I don't think that you did this one.
example of same request giving different csrf-token
here the images shown are both the examples of one of my app for a specific request
We do often confuse second with the first one. In the second case, the server sets a cookie in the first get request with a csrf token (this is a cookie and not the csrfmiddlewaretoken ), it needs to be sent every-time for csrf cookie verification. This is done by the browser itself and we mostly don't notice it. However the problem arises with using CORS (different origins of request like android/angular app etc).
Trying to grok this e-commerce scenario...
I build an amp product page in amp that has the new amp-form
The add to cart button is an XHR to my backend (that is session based, using
cookies by default)
User searches for product and results take them
to my amp product page, but they've never been to my site
They submit the add to cart form
the CORS preflight makes it's way to my backend, and i set all the correct allows as per https://github.com/ampproject/amphtml/blob/master/spec/amp-cors-requests.md
Now the actual request is made... backend initializes a session,
returns session identifier as a cookie, but since user never went to
my site...just the google amp cache it's treated as a 3rd party
cookie and browser discards it (cause user disables 3rd party cookies)
users session is lost, as is their add to cart action
So the question is, how do i keep the session around and the item in the cart?
Am i missing something? is there a trick i'm not seeing?
appreciate any insights.
Associating the shopping cart with the CLIENT_ID would be the best way to solve this problem. Unfortunately, transferring the CLIENT_ID via forms is not yet supported in AMP. It's currently being implemented, you can watch this issue for the current status.
Here is an approach that works right now: the idea is to encode the shopping cart content into a string that is returned in the form result. This way we can generate "View Cart" and "Checkout" links including the shopping cart content. Once the user clicks on one of those links, you can create the actual shopping cart in your backend and store the user id in a cookie.
For example:
<form action-xhr="/add-to-cart" method="POST">
<input type="hidden" name="itemId" value="headphones-123">
<!-- Hide after form submit success -->
<input type="submit" name="add" value="Add to Cart">
<div submit-success>
<template type="amp-mustache">
<!-- shopping cart contents, e.g headphones-123 -->
{#shoppingCartContent}
View In Cart
Checkout
{/shoppingCartContent}
</template>
</div>
<div submit-error>
<template type="amp-mustache">
{{message}} <!-- e.g. Only 2 Headphones are left. -->
</template>
</div>
</form>
The disadvantage of this approach is that the shopping cart will be lost when the user leaves the page without viewing the cart first. This will be solved once the CLIENT_ID can be passed via amp-form.
I also know very limited info about AMP pages but I suggest that you please read through the use of User identification and try using an AMP-generated client ID. As mentioned in the documentation:
By default, AMP will manage the provision of a client ID whether the page is accessed from the publisher's original website or through a cache.
Likewise, learn more about client ID substitution, including how to add an optional user notification ID, in Variables supported in AMP analytics.
Hope that helps!
I have a facebook timeline page tab app that's running inside an IFRAME on a fan page.
On the main page of the app, we show 10 jobs and users can click through to the detail page of one single book.
We want to add a LIKE button on those detail pages, so that users on facebook can like and share that job in their stream.
The app is totally dynamic so different customers can install the app on their fan page and list their own jobs. (ex. coca-cola installs it on his coca-cola page and lists jobs within the company. then microsoft installs it as well and does the same)
The problem concerns og:metatags and redirection of the liked detail page link, right inside the right facebook company page and relative right detail page showing the job.
I can get these two things done and working but not at the same time:
A. Facebook gets correctly the og:metatags in the head section, with image, title, description when I use the following implementation of the like button (without "data-href" extra attribute)
<div class="fb-like"
data-send="false"
data-layout="button_count"
data-show-faces="false"
data-action="like"
data-font="arial">
</div>
The problem is that not specifying the data-href attribute (and the og:url meta is totally ignored) this is gonna create a link to the current page => intended current page inside an iframe => so the result will be that when you click the shared job on facebook you will be redirected NOT inside the facebook app -right page -right detail page, but to the detail page on the server that hostes the app.
B. If I instead specify the data-href attribute
<div class="fb-like"
data-href=<%= "http://www.facebook.com/pages/:page/#{session[:fb_page_id]}?v=app_XXXXXXX&app_data=#{#job_details.job_id}" %>
data-send="false"
data-layout="button_count"
data-show-faces="false"
data-action="like"
data-font="arial">
</div>
Doing this I can get the right link posted on facebook (so then using &app_data attribute) I can get the perfect redirection working.
BUT on the downside, the og:metatags are totally ignored and instead facebook picks the page tab metatags (top iframe that hostes the pagetab app) and so I get posted on facebook a crap link that tells about a page on facebook with the page app picture. And the even bigger downside is that when you like a job on the app, all the jobs appear to be liked as well (basically the iFrame app becomes the liked page... instead of being the job detail page picked as liked page)
Is out there any genius that knows how to sort this out? I need to get the A an B working at the same time to get the requested result!!!!
Please help!!! :(
I've found the solution myself.
Like button => use href and ref attributes, especially put on the ref the id of your facebook fan page. Passing the current page url will also load and share correctly the og:metatags.
<div class="fb-like"
data-send="false"
data-show-faces="false"
data-layout="button_count"
data-font="arial"
data-action="recommend"
href=<%= "https://app.com/jobs/job_details.job_id" %>
ref=<%= FB_PAGE_ID %>>
</div>
Once you pass the ref attribute to facebook, on your wall the link will be posted by facebook with an extra query string appended with in particular the "fb_ref" parameter:
for example a button with parameters:
href=<%= "https://app.com/jobs/job_details.job_id" %>
and
ref=<%= 332325142248470 %>
becomes:
https://app.com/jobs/a0Ed000000a54bkEAA?fb_ref=332325142248470&fb_source=profile_multiline
when the user clicks the link we want to be redirected back right inside the correct page tab app and right job details page. To achieve this we set up into the controller/show action (that in ruby corrisponds to controller_name/id) a new redirection, remembering that ref will put inside a query string after our href link:
if params[:fb_ref]
redirect_to "http://www.facebook.com/pages/:page/#{params[:fb_ref]}?v=app_xxxxx&app_data=#{params[:id]}"
end
As you can see we create a new dynamic url that will use the "app_data" parameter of the facebook "signed_riquest" (http://developers.facebook.com/docs/authentication/signed_request/) in order to pass to our application the right detail page to be visualized and also redirect us to the right facebook page.
once done this we have just to manage correctly the new app_data parameter that comes now with the signed_request. In my case in one of my main controller I've used:
if fb_signed_request[:app_data]
redirect_to "/jobs/#{session[:app_data]}"
end
And we will see our app loading the right page and the right job detail page!
Hope is gonna help other people!