Jump to content

Mega

Members
  • Content count

    9
  • Joined

  • Last visited

Community Reputation

4 Standard

About Mega

  1. Mega

    backgrond https

    What do you mean by "no longer safe"? The imagizer subdomain does not get login cookies from Imageshark, it is a subdomain for images sharing. SSL/TLS will not save you from attacks, it is just a way to authenticate the connection between the client and the server, and encrypt the text fields. Then it does not need to be encrypted. But if this happens to any site, then they should be using https.
  2. Mega

    Safer codes for xat.me and groups

    Because it is necessary to give suggestions, So they can think about it. They will add soon, Maybe.
  3. Mega

    WIN STATUSCOLOR - LUCK CONTEST

    g4Pu06B8b5k5HJusDHG6SJb6SJbC
  4. Mega

    balloon game

    Now you can add this game to XS/Chats(EMBED): [box:bs:width:height:1]
  5. Mega

    Flash Problem On Chrome

    The Google team said that blocking some embeds are cause of their size, 1x1 are always blocked according to the current updates. In the future they are planning to update this lock. To be more strict or less restricted depending on the interaction and others things. Then i've tried changing the size and it worked here, So i don't have to enable unsafe configurations. Check: https://www.chromium.org/flash-roadmap
  6. Mega

    balloon game

    Is it a multiplayer game? I like it
  7. Mega

    Issue on the forum

    It seems to be a caching problem. Maybe this is some configuration. I found the "Must-revalidate" field in the response that might be considering the redirect page as the same page. Error header: HTTP/1.1 503 Service Unavailable Date: Mon, 06 Mar 2017 13:32:13 GMT Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Connection: keep-alive X-Frame-Options: SAMEORIGIN X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block Server: cloudflare-nginx CF-RAY: 33b5ae05c5854b81-GRU 4b6 --- Its the response body, 4b6 is seems a part of the CloudFlare cache code, I searched here and did not find any of my requests that had this cache. Check: https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4 *. If the response includes the "must-revalidate" cache-control Directive, the cache MAY use that response in replying to Subsequent request. But if the response is stale, all caches MUST first revalidate it with the origin server, using the Request-headers from the new request to allow the origin server To authenticate the new request. Try using only no-store and no-cache. Also, POST requests are not being redirected to HTTPS, Only the links have been modified to https. Probably because of the IPS configuration. I got it on the POST request: HTTP/1.1 200 OK Date: Mon, 06 Mar 2017 13:20:50 GMT Content-Type: text/html;charset=UTF-8 Content-Length: 62484 Connection: keep-alive Set-Cookie: __cfduid=----; expires=Tue, 06-Mar-18 13:20:49 GMT; path=/; domain=.xat.com; HttpOnly Set-Cookie: ips4_IPSSessionFront=SOMESESSION; path=/; secure; HttpOnly X-Frame-Options: SAMEORIGIN X-Content-Type-Options: nosniff Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate Pragma: no-cache X-XSS-Protection: 0 Server: cloudflare-nginx CF-RAY: 33b59d57153f4a96-GRU I do not know if the problem is the Cloudflare, But you shall check it HERE . Mega
  8. Mega

    hair power

    Hahahaha omg
×