Slack's files.delete API always returns cant_delete_file error - slack

I am trying to write a script to delete old files from my Slack workspace.
Following the Slack API docs, I created an app, gave it the channels:join, channels:manage, channels:read, files:read, and files:write scopes, and installed it in the target workspace.
My app can list channels, join a channel, and list files in that channel, but whenever I try to delete a file, I get a response that looks like this:
DELETE https://slack.com/api/files.delete?token=xoxb-xxxxxxxxxxxx-xxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx&file=Fxxxxxxxxxx
User-Agent: PostmanRuntime/7.24.1
Accept: */*
Cache-Control: no-cache
Postman-Token: 8f6854b4-794c-4685-892c-c9fafc03827e
Host: slack.com
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
HTTP/1.1 200 OK
date: Sat, 09 Jan 2021 19:23:28 GMT
server: Apache
x-xss-protection: 0
pragma: no-cache
cache-control: private, no-cache, no-store, must-revalidate
access-control-allow-origin: *
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-slack-req-id: 227ef4f9bb4c85c42d6f1c7fb33ddac0
x-content-type-options: nosniff
referrer-policy: no-referrer
access-control-expose-headers: x-slack-req-id, retry-after
x-slack-backend: r
x-oauth-scopes: files:read,files:write,users:read,channels:read,channels:join,channels:manage,remote_files:write
x-accepted-oauth-scopes: files:write
expires: Mon, 26 Jul 1997 05:00:00 GMT
access-control-allow-headers: slack-route, x-slack-version-ts, x-b3-traceid, x-b3-spanid, x-b3-parentspanid, x-b3-sampled, x-b3-flags
vary: Accept-Encoding
content-encoding: gzip
content-length: 59
content-type: application/json; charset=utf-8
x-envoy-upstream-service-time: 26
x-backend: files_normal files_canary_with_overflow files_control_with_overflow
x-server: 10.128.70.109:80
x-via: envoy-www-iad-kyvf, haproxy-edge-iad-2ql3
x-slack-shared-secret-outcome: shared-secret
via: envoy-www-iad-kyvf
{
"ok": false,
"error": "cant_delete_file"
}
According to the API docs for the files.delete endpoint, cant_delete_file means:
Authenticated user does not have permission to delete this file.
I can only assume that this is because my user is a bot, and is not the user who originally uploaded the file.
Because I am the workspace admin, I expect that I would be able to list and delete all files if I were to authenticate with my user credentials, but the Basic App Setup docs don't say how to authenticate with user credentials, even though they contain language suggesting that some actions may require a User Token:
If you need to act as a specific user (for example, posting messages on behalf of a user, or setting a user's status), you'll need a User Token.
Is anybody aware of how to either:
Delete a file when authenticated with an App Token; or
Obtain a User Token from within an app?

Although it isn't clearly documented, App Tokens are not allowed to delete files that were uploaded by other users.
In order to do this, the App needs to be installed into the workspace via OAuth, granting the app a User Token that inherits the permissions of the user who installed it.
If that user is the workspace administrator, the app will be able to delete any file, regardless of who uploaded it. See https://api.slack.com/legacy/oauth for details

Related

Safari set-cookies not working for first party cookie

When I login, I return to the browser:
Overview
URL: https://subdomain.domain.de:8444/api/auth/login
Status: 200
Source: Network
Adresse: xxx.xxx.x.xx:8444
Initiator:
xhr.js:177
Request
POST /api/auth/login HTTP/1.1
Accept: application/json, text/plain, */*
Content-Type: application/json;charset=utf-8
Origin: https://subdomain.domain.de
Content-Length: 62
Accept-Language: de-de
Host: subdomain.domain.de:8444
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Safari/605.1.15
Referer: https://subdomain.domain.de/login
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Response
HTTP/1.1 200
Access-Control-Allow-Origin: https://subdomain.domain.de
Content-Type: application/json;charset=UTF-8
Pragma: no-cache
Set-Cookie: accessToken=FycxgaSUgHnBlzMqYn/qsBEm5YBcmX52/eYbm+daUHPP1Fa7edawdawdawO1EdJlz9nyP5FrlPYnh/b//SZJRDs0Am8sGF+UZ+XffvPra8awdawd9+RbHiN0WcL+9T4xLlueMxd5bNVRVKHqeTonSK02Ym0cLxfALOeHrmbdqLS95uNOlzFYbjOuGV7bhwLGk5bavNPv9IWKqNAILAbkkw+gdawdawduM+BXdGE7KFbUgxvGmDw==; Path=/; Domain=subdomain.domain.de; Max-Age=PT448343981H30M29S; Expires=Sat, 16 Apr 2072 22:57:46 GMT; Secure; HttpOnly;SameSite=Lax
Set-Cookie: refreshToken=FycxgaSUgHnBlzMqYn/qsBEm5YBawdawdadawdupnO1EdJlz9nyP5FrlPYnh/b//SZJRDs0Am8sGF+UZ+XffvPra84jWTk9+RbHiM1+aNElVA8jXewqlexh7tGKuawdawdv4pxzC/RsDoGS/Jc8Xkzg133dYMCr7mRHlkU7jijoJrPYUAayiewVIMPUh/IE8sGUqIMKbiGoqAJAawdawdawdawdawdaw03GS4XgbwFj76V2AAAw==; Path=/; Domain=subdomain.domain.de; Max-Age=PT450502981H30M31S; Expires=Fri, 15 Jul 2072 21:57:46 GMT; Secure; HttpOnly;SameSite=Lax
X-XSS-Protection: 1; mode=block
Expires: 0
Transfer-Encoding: Identity
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Date: Mon, 22 Feb 2021 22:58:53 GMT
Access-Control-Allow-Credentials: true
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
Request data
MIME-Typ: application/json
Codierung: utf-8
Anfragedaten:
I also see, the cookie in the response:
But the cookies are not saved in the browser. This is a first party cookie which I am creating in my spring backend.
In Spring Boot, I create the cookies like this:
import org.springframework.http.HttpCookie;
import org.springframework.http.ResponseCookie;
#Component
public class CookieUtil {
public HttpCookie createAccessTokenCookie(String token, Long duration) {
return ResponseCookie.from("accessToken", token).maxAge(duration).httpOnly(true).path("/").build();
}
public HttpCookie createRefreshTokenCookie(String token, Long duration) {
return ResponseCookie.from("refreshToken", token).maxAge(duration).httpOnly(true).path("/").build();
}
}
There are a great number of problems related with Safari and the use of cookies, if you look up for information related with the problem you will find multiples bugs and solutions, ones appropriate for some cases, and ones for another.
Although Lax is preferable (please, see this great article), one thing you can try is setting your cookies SameSite attribute to None. Be aware that this change maybe could be relevant and affect the application behavior in other browsers, especially Chrome.
Another thing you can try is setting the domain for the cookie to something like .domain.de or domain.de to avoid any possible subdomain related problem.
Finally, please, pay attention to the fact that in your screenshot it seems that the value for max age is not printed correctly. Probably not but perhaps a similar issue, for the same version of Safari you indicated, has been reported here on SO in this question: the OP solve the problem by adjusting the value of the max age cookie attribute. Please, try different values for that information, maybe it works.
According to your comments, for future reference, in some way the problem seems related actually with the cookie max age: removing max age value from the cookie looks like a temporary workaround for the problem.
In safari you ll have to ask the user to allow the use of your cookie.
As of ITP 2.1, Safari uses its machine-learning magic to identify which first-party cookies can be used for tracking. Then, it blocks cookies unless you use the Storage Access API to ask users to allow the use of your cookie.
you can further read on how to use this here https://developer.mozilla.org/en-US/docs/Web/API/Document/requestStorageAccess

Disable caching of content in firefox offline mode

I am working on a web application which has user management in place. I find a concerning issue in firefox related to Work Offline. Following are the steps describing the scenario:
User logs in to the application
User performs some action and logs out of the application
If the user now enables Work Offline mode in firefox, he/she can use browser back to access the last page. However, this page is supposed to be secure.
In my opinion this is a data security issue as any other user can apply this technique to fetch valuable information of the last user.
I have used cache control headers to communicate to the browser that HTML content should not be cached. Following are the response headers used:
HTTP/1.1 200 OK
Date: Tue, 05 May 2015 10:39:30 GMT
Server: Apache/2.4.9 (Unix) OpenSSL/0.9.8za
Cache-Control: no-cache, no-store
Expires: Wed, 31 Dec 1969 23:59:59 GMT
Content-Type: text/html;charset=UTF-8
Content-Language: en
Vary: Accept-Encoding
Content-Encoding: gzip
X-Frame-Options: SAMEORIGIN
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
I have used
Cache-Control: no-cache, no-store
Expires: Wed, 31 Dec 1969 23:59:59 GMT
I have noted this vulnerability in applications like Facebook. Is this resolvable? Thank you.

What is the endpoint to make batch request for Google Calendar v3 API

I want to make a batch request (get, insert, update, delete) to Google calendar api v3 from Salesforce.com, I'm using http request, the problem is that I can't find the endpoint for batch request in the google documentation, there is an fictional demo on the documentation but is no clear.
Somebody know the endpoint to make the batch request for google calendar api v3?
I have tried the following to request the batch, using OAuth 2.0 Playground tool:
POST /batch HTTP/1.1
Host: www.googleapis.com
Content-length: 91
Content-type: multipart/mixed; boundary=batch_foobarbaz
Authorization: Bearer we28.1.AADtN_Xs2wsTqnathLdU-X0q1Zwur2Rhi4AossFeGlbaPeavLZ6u5Jm4L3sTbuY
--batch_foobarbaz
Content-Type: application/http
GET /calendar/v3/calendars/primary/events
But I get this error:
HTTP/1.1 500 Internal Server Error
Content-length: 13
X-xss-protection: 1; mode=block
X-content-type-options: nosniff
Expires: Fri, 01 Jan 1990 00:00:00 GMT
Server: GSE
Pragma: no-cache
Cache-control: no-cache, no-store, max-age=0, must-revalidate
Date: Wed, 30 Apr 2014 21:29:50 GMT
X-frame-options: SAMEORIGIN
Content-type: text/html; charset=UTF-8
Unknown Error
Someone idea how to make it work?
Your request is missing the end marker, it should be:
POST /batch HTTP/1.1
Host: www.googleapis.com
Content-length: 91
Content-type: multipart/mixed; boundary=batch_foobarbaz
Authorization: Bearer we28.1.AADtN_Xs2wsTqnathLdU-X0q1Zwur2Rhi4AossFeGlbaPeavLZ6u5Jm4L3sTbuY
--batch_foobarbaz
Content-Type: application/http
GET /calendar/v3/calendars/primary/events
--batch_foobarbaz--
See a full example here.
The endpoint is
https://www.googleapis.com/batch
That works for me when I do Calendar batch requests. One problem I had was with my last boundary token I didn't have the -- after it. So each token starts with -- and the last one has -- at the end. You will also have to do what #Vinicius Pinto says.

What would cause SmartCloud to redirect a REST call to a login page?

I am not using the SBT, but making direct REST calls with Abdera to the current version of Connections on IBM SmartCloud. REST URL in question: https://apps.na.collabserv.com/search/serviceconfigs
Observations
When testing from my laptop (using Firefox and the REST client add-on,) this works as expected. I get back an ATOM feed.
When testing from a server (on a different network,) using the same method (Firefox + REST client,) I get back HTML that is a log-in page.
In addition, I get this same result when I call the URL from a Java program on the same server.
In all cases, I am using the same credentials with basic authentication.
Update: If I log into SmartCloud first, on a separate tab in Firefox on the server, then call the URL as before, from another tab, it works. I get the ATOM feed as desired. Naturally, this is unsuitable as a solution, but I present it as additional information that could lead to an actual solution.
Update: Further testing shows that the local (laptop) log-in exhibits the same behavior as the server. A form-based log-in is required from the same browser, then subsequent REST calls work.
Update: Here is a relevant simplified code snippet:
private static Abdera ABDERA = new Abdera();
private static AbderaClient ABDERA_CLIENT = new AbderaClient(ABDERA);
...
String host = "https://apps.na.collabserv.com";
ABDERA_CLIENT.addCredentials(host, AuthScope.ANY_REALM, "basic", new UsernamePasswordCredentials("user", "password"));
...
ClientResponse response = ABDERA_CLIENT.get("https://apps.na.collabserv.com/search/serviceconfigs");
Summary
It appears that something about the originating server or the call is causing SmartCloud to respond with a log-in page. Whereas, the same call and credentials from my laptop, work as expected.
Question
Where should I start to trouble-shoot this? How can I build the client credentials to allow programmatic log-in?
Response Headers
If it helps, here are the response headers that I get back in each case.
Unsuccessful
Status Code: 200 OK
Cache-Control: no-cache
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 1850
Content-Type: text/html
Date: Tue, 08 Oct 2013 14:15:03 GMT
Pragma: no-cache
Server: WebSEAL/6.1.1.3 (Build 110428)
Set-Cookie: PD-H-SESSION-ID=4_0_IR4***masked***oRKlJI;secure; Path=/; HttpOnly BIGipServerE3A-WebSEAL-80-fe=2132806922.20480.0000;secure; path=/
Vary: Accept-Encoding
p3p: CP="NON CUR OTPi OUR NOR UNI"
Successful
Status Code: 200 OK
Cache-Control: public, max-age=86400, s-maxage=86400, no-cache=set-cookie, private, must-revalidate
Content-Encoding: gzip
Content-Language: en-US
Content-Length: 1164
Content-Type: application/atom+xml; charset=UTF-8
Date: Mon, 07 Oct 2013 17:21:12 GMT
Expires: Tue, 08 Oct 2013 17:21:12 GMT
Server: WebSphere Application Server/8.0
Vary: Accept-Encoding
p3p: CP="NON CUR OTPi OUR NOR UNI"
x-lconn-auth: true
x-powered-by: Servlet/3.0
#Grant is your login using SAML? I could see this redirect happening. also could be TFIM related... maybe you should grab the auth on a different page, store the cookies, and then try connecting to the endpoint above.

Double Set-Cookie in Magento, leading to a login issue for some users

We have a Magento application which is issuing dual Set-Cookie's . Here are the headers:
HTTP/1.1 200 OK
Date: Wed, 18 Apr 2012 21:04:28 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.2.10
Set-Cookie: frontend=iti6c00cdm6cc79hfl1pl9pq52; expires=Wed, 18-Apr-2012 22:04:28 GMT; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: frontend=iti6c00cdm6cc79hfl1pl9pq52; expires=Wed, 18-Apr-2012 22:04:28 GMT; path=/; domain=**example.com**
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
In some circumstances, after logging in the second cookie is set to frontend=deleted . From my reading it appears that two frontend= cookies are not a "problem", this is standard Magento behaviour. From my reading of the spec, the second frontend= cookie will overwrite the first if their scope/spec is the same.
Any ideas where we can start digging in to this problem to see why the second frontend= cookie does not behave like the first?
Magento version is enterprise edition of ver. 1.9.0.0
Related Questions
Why does Magento use 2 cookies per session?
Magento Cookies Changing Prevent Frontend Login
This happens when the Session validation checks fail - the cookie will then be cleared with the "deleted" value and a expiration date in the past:
The following information will be checked by Magento for validating a session:
The client IP address that is connecting to the server
The "Via" HTTP-Header
The "X-Forwarded-For" Header
The "User-Agent" Header
If one (or more) of these informations changes during the requests for the same Session ID, the session will be Discarted, the Cookie will be cleared in the way as described and the Server will send a Redirect header to the Homepage.
You can change which Information to validate in the Magento Admin-Panel by going to System > Configuration > Web. But you should never turn off all checks since this will allow session hijacking.
Do you want to override fronten cookie... if so better try to first destroy the cookie and then reset it by using Magento method
Mage::getModel('core/cookie')->set('frontend', $session->getCustomer()->getId(), 100000*24*3600);

Resources