@Athan thanks! So if I understand correctly, the Forge app will list fine-grained scopes that the Administrator / User will have to agree to. The Connect app will be able to authenticate using the Client Credentials and will assume the permissions as defined in the scope of the Forge app? So there will be no additional user interaction.
2 Likes
@remie, I really wish it will be like this.
@jhazelwood what is preventing you from changing Connect authentication layer without sunsetting the platform?
Technically, there is no reason why Connect cannot be migrated to OAuth (assuming the app-based service account with Client Credentials approach as mentioned here 22 Sep 2021 - Unifying Atlassian Connect and Forge: An Update - #20 by Athan) or that the security of Connect cannot be improved without forcing Marketplace Partners to move to Forge.
In fact, there have been a lot of security related changes to the Connect framework in the past months, so obviously it is still worth the investment and there is still room for improvement.
So I’m going to draw the Open Company, No BS card: what is the reason for sunsetting Connect?
12 Likes
Second that!
3 Likes
I think this is a good example of why partners could use a single entry point for partner support for help on any issue related to being a partner w/ Atlassian. Marketplace, Billing/Licensing, Dev, ProdOps, etc. A partner support ticket that Atlassian routes to the right team in Atlassian and Atlassian opens issues in the other systems they use to track it and follows up with the partner according to an SLA.
IMO, it’s not going to work to have partners use a Jira project containing hundreds of open issues on some specific area/framework (like the Forge Jira project). Letting customers open bugs in your bug tracking system is a recipe for having a backlog that is overloaded with poorly written bugs, in my experience. Also, there is no commitment from Atlassian in such a system. Partners need a ticket.
There are several areas we work in (I specialize in Server/DC plugin dev/support and I do some frontline support for Cloud). It is hard to remember where to report what and after we report it then it is hard to track.
I’ve said this before in other forums/channels so I’ll stop now, I know that Atlassian is working on it but it is so important that I wanted to say it one more time. Thanks.
14 Likes
@Athan will this support user impersonation (asUser) the same way JWT does?
5 Likes
@AditiVenkatesh you wrote this:
I don’t know that this is necessarily a true statement. There is already indication that more and more features are going to be Forge only, leaving folks on the connect side lagging in capabilities. A good example of this is integration with Automation for Jira. That was recently announced as a Forge only feature.
3 Likes
I’d like to know how this plays into the cloud migration strategy that Atlassian is pursuing. Atlassian is asking vendors to make cloud versions of our server/dc apps and then asking us to build it on a deprecated platform. Why would we do that now? Wouldn’t it be better to delay migrations until Forge is fit for purpose?
Another question I have is what the experience is of Atlassian porting their own Connect apps to Forge? Are Atlassian eating their own dog food.
I see the eventual value that customers get in increased trust but I don’t feel that the only way to get that is via a re-write on a new platform. One way to look at this is to see it as another set of Atlassian mandated busy work that is getting in the way of app vendors from shipping value to our shared customers.
23 Likes
@AditiVenkatesh @jhazelwood Just flagging [JSWCLOUD-18874] OAuth 2.0 for all the JSW REST API endpoints - Create and track feature requests for Atlassian products. as a huge blocker for moving to Stage 2. This isn’t really a Forge limitation per se, but the Agile API is necessary for our apps to work.
2 Likes
Does this mean that Confluence is dropping support for macros for anonymous users?
As use of Forge for macros seems to require an authenticated user, does this mean that people who use Confluence for end user documentation will have to look for alternatives? Or will Forge move to support anonymous users in the future?
7 Likes
Will JSM customers be able to authenticate with Oauth 2.0?
Hey @alan.parkinson and @BobBergman ,
Thanks for asking about BBC. As you know, BBC has its own connect app framework and currently isn’t factored into the discussed ‘connect and forge’ unification project. This also means that any quoted depreciation date does not apply to BBC connect apps.
Apologies for any confusion here, the BBC team are working hard to clarify our Forge / Connect support roadmaps, but aren’t ready yet to share any details here at this stage. In the meantime, BBC’s connect app framework will remain the recommended & supported way to integrate with BBC.
2 Likes
Hey @david
Support for anonymous users on Forge is something that has been roadmapped by my team - expect to see this functionality rolled out in the next couple of quarters.
6 Likes
Hi @david2
We are currently investigating how user impersonation will look for Connect-on-Forge and will be sure to keep everyone updated regarding progress on this.
1 Like
Hi @TureHoefner
Yes, I definitely agree with you that this is an important matter. We take developer feedback very seriously and are continually working towards improving the way in which we support our partners. Thanks for raising this again, and I will ensure that the relevant teams are made aware of this.
Hi @jmort
Connect-on-Forge is designed to enable you to take advantage of both platforms. This means not only can you continue to migrate your server/dc apps now but soon you will also be able to incrementally lean on more Forge functionality as we continue to build out the platform.
Regarding dog fooding this process, yes we definitely plan to try this out ourselves once we have completed building the functionality required to do so. So far, we have tested out the alpha release. We aim to be transparent about our experiences and have documented the limitations identified which we are actively working towards overcoming.
2 Likes
Hi @AditiVenkatesh ,
in your investigation, please keep in mind that background apps, such as automation apps (e.g. JMWE) need to be able to impersonate users without requesting their consent, for 2 reasons:
- the app operates in the background and thus doesn’t have a user interface to request this consent
- the users don’t even know about the app, which is installed and configured by admins
6 Likes
Hi @AditiVenkatesh ,
dogfooding is not the same as “trying this out ourselves”. Dogfooding requires you to implement commercial products using the same functionality third-party vendors must use.
To give you an example, when Salesforce built their force.com platform, they simultaneously built their BI solution on top of it, which ensured that the platform would be useable to build commercially viable apps.
14 Likes
Hi @AditiVenkatesh ,
I think you’ve missed my point about Migrations. What you’re asking vendors to do here is write cloud versions of server/dc apps to in Connect (a now deprecated platform). We’ll then have to re-write then for Forge. The re-write to Forge is busy work that provides essentially no value to customers, but costs us development time where we could be delivering value. The Cloud Migration strategy and push to Forge do not appear to be aligned from a vendors perspective (and there fore customer impacting).
@david2’s point about dogfooding is spot on. We don’t want toy apps, we want Atlassian to have something valuable to risk. What about porting Insight Asset Management to Forge?
13 Likes
@remie that’s right, the admin will agree to a set of scopes on install so the app can authenticate (as itself, not as a user) without user interaction.
2 Likes