I'm adding messages that includes url markdown to a slack channel using this format:
<http://somesite.com|friendly name> -> works
<mailto:email#domain.com|friendly name2> -> works
<sip:email#domain.com|friendly name2> -> url markdown doesn't works
When I use <sip://email#domain.com|friendly name2> the markdown convert it to link but the sip client fails to connect due to the extra "//"
Any idea how to make sip links on slack?
Slack's documentation only mentions http/https and mailto schemes for automatic linking, but I played around with their message builder and noticed the following:
Schemes followed by :// seem to be generally supported
In addition there seems to be a whitelist of other schemes supported. The only ones I found working so far are mailto and skype.
While that matches your observation it looks like there is no way to have automatic linking for the sip scheme.
What you could do is to write a Slack App, which provides a command (e.g. /sip email#domain.com), which will print a link to a website which redirects you to the proper sip-URL. I believe that's the approach other services like Zoom use as well for their Slack integration.
An interesting alternative could be to contact Slack and kindly ask them to add sip-URLs to their whitelist.
Related
I have a not yet published app change in Slack which modifies the command service endpoint to another domain.
I tested that, it is possible to send back a 307 with a redirect URL and Slack API will follow that redirect.
I would like to be sure that redirect to another domain is also possible for live apps. So what works for an in-development app it will work for a live app.
Could any of you confirm that or send me a link to the documentation? I searched the documentation already, but did not find any entry about it.
Thanks!
We contacted Slack on their partner channel and they verified that:
"Our docs explicitly say we respect 301 and 302."
But we made a test and it accepts 307 as well.
(I can't share a link to their response as it was written inside Slack slack-platform workspace)
I am trying to set-up universal links for an iOS app.
The Apple search validator keeps failing when I try to validate the file apple-app-site-association with error message:
Unable to parse that webpage URL. Try a different URL.
The file content is correct, I tried with already validated files from other websites but it seems the crawler fails to access the website generally.
The domain and website are hosted on a shared server at 1and1.com without SSL. The file is not signed.
Any idea why that is?
This is the "App Search API Validation Tool", not the "Universal Links Validation Tool" (which doesn't exist from Apple). The results from this tool have no connection to whether Universal Links work or not.
That said, you must have SSL in order for Universal Links to work. That is the number one requirement. If you can't/don't want to set this up, look at an external link hosting service like Firebase Dynamic Links or Branch.io (full disclosure: I'm on the Branch team)
In reference to "you must have SSL in order for Universal Links to work. That is the number one requirement." This is no longer a requirement.
If your app runs in iOS 9 or later and you use HTTPS to serve the apple-app-site-association file, you can create a plain text file that uses the application/json MIME type and you don’t need to sign it.
When responding to a slash command with a string that includes a channel ID like <#C3989289>, the response in Slack shows a deep link to that channel "#general.
When I do the same for a direct message or IM, the response in Slack shows "#deleted-channel" and it's not a link.
I don't see anything in the docs about why this: https://api.slack.com/docs/message-formatting#linking_to_channels_and_users
Slack has confirmed that their system is designed in this way to protect private channels/direct messages from being made aware to users, even if the recipient of the message containing the deep link does belong to that particular channel/DM.
I'm trying to register my App on Venmo's developer site so that I can properly use their API, but I'm stuck trying to figure out what the required "Web Redirect URL" field is for. According to the docs, it says it is the following:
Venmo will redirect your users to this address. Must be formatted like
http(s)://www.example.com/example_redirect_url
As far as I could gather this was a URL scheme that would allow Venmo to redirect you back to your app after payment processing was completed on their side, but in researching how to set up a URL scheme the format is something like "[scheme-name]://", not "http://...."
The other thought I had was that this was just a url that contained a server-side or javascript redirect to that aforementioned URL scheme, but that seems like an unnecessary extra step. I also have a few other theories on what it could be, so I'm really just not sure which one it is...
I was running into the same problem. If your website is deployed you can use the redirect that your hosting service provides you. If you're not deployed then you can set it localhost.
Example: http://localhost:8000/auth/venmo/callback
I am an ios app developer. We have implemented a custom URL scheme 'my_app://section_name' or so where if the link is opened in the user's mobile browser, it will redirect the user to a specific section in the app.
We would like to be able to tweet these URLs and have users on their mobile device click on them to open up the app, however it just can click once
(when you click close , maybe you click wrong then you want to click it second but it does not work )
I hope this isn't too silly of a question. Thanks
Make sure to check the tweet body after it have been posted.
This may be due of an URL shortener, especially if the tweet is posted from the iOS 5 Twitter framework.
I'm having a similar issue with url schemes. We can include them in emails and text messages, and they highlight and work properly.
Unfortunately, when we do the same with a tweet, the iOS Twitter client fails to recognise the special URL scheme and so the user cannot tap on it to open our app.
Pretty big oversight, methinks. Anyone else had any joy including special URL scheme links in tweets?
A solution that you should consider involves not sharing the URI scheme directly, but rather creating a page on your web server to handle this. In fact, if you want to be able to share full URI schemes with paths, you're better off building a web server to dynamically generate a page with a URI scheme redirect.
This is a over-simplified representation of what we built at Branch. This includes some code to get you started though the web server will require a bit of setup not described here.
instead of testapp://some.data.here, you'll link to http://yoursite.com/hosted-redirect/some.data.here.
your server should listen at the route /hosted-redirect, grab some.data.here and build the following page (body here):
(source: derrrick.com)
So your server will have to generate and respond with this page, filling in some.data.here, anytime http://yoursite.com/hosted-redirect/some.data.here is requested.
A lightweight node app could do this with a single file.