Passport.js integration

[Notum]

@George

It is still work in progress

Exactly as I thought!
I believe biggest challenge (I might be wrong) is to support all (or at least top 10) of passport.js strategies. As well as sessions that passport.js generates to be support by Wappler.

[tbvgl]

That’s good to know Just started working on an extension

[scalaris]

Bump.

Love to hear about progress on this as we’re aiming to deploy in Q1 2024.

Thanks

[Digo]

Bump

Any update to this?

[Notum]

Bump!

[Digo]

Bump

[hs-rene]

Bump from me too. This would be great to see please

[karh]

@George
I've seen some passport.js related stuff in the updates recent weeks/months.

Can you give a tiny update on that? And if it will include passkey support and if it includes passwordless stuff?

[Vamberto_Farias_Winn]

Good morning, any predictions on this feature? Will it really be implemented?

[Digo]

Can we please get an update to this? It's been nearly 7 months since this was apparently in progress, with no updates since then. If it's not happening anymore, it'll be nice to know so we can work on alternative implementations rather than waiting an unspecified amount of time for this to possibly be implemented.

[pixlapps]

Bump Bump

[Cheese]

Patrick recently replied regarding Passport JS integration in to Wappler, the response is below:

@patrick

The main problem with the passport integration is that it can't be integrated with serverconnect app instance. The serverconnect app instance is initialized on the route handler and is per request an other instance. The passport middleware runs before the serverconnect app is initialized and also has no access to any of its functionality.

As you notice in the documentation for example the passport-auth-token . You will need to program a part yourself, it only passes the authtoken to the callback function where you then have your own program logic and here we will not have access to serverconnect data or database connections.

The serverconnect app was originally not developed for NodeJS, the first version were for PHP and ASP. Later it was ported to NodeJS and kept fully compatible with the other versions. We have the advantage that we have full control over the server with NodeJS, but also the disadvantage that the code is based on PHP/ASP with its per request instance.

Middleware in NodeJS that do not depend on App logic (database connections etc) can be used without problem. Most of the passport middleware require you to have some app logic (like lookup user or token in a database) and without access to serverconnect instance at that moment it will require custom JavaScript coding.

I would have setup serverconnect for NodeJS differently now so that it would make use of the full functionality, but then it would be totally different from PHP/ASP. The filosofie of Wappler is that it should not matter which server model you use, they should all behave exactly the same.

Read more here.

[JonL]

The very same reason why I never bumped my own feature request. When I opened this feature request in 2020 I didn’t have a real understanding of how AC and SC worked.

Later on, when hitting some roadblocks I started to look into the two frameworks code in more detail. Finally with extensibility I started to learn more about the architecture as a whole and learnt the hard way that there would be some things that would never fly with the current architecture.

Hence why I have been so against PHP and ASP to remain as first class citizens in Wappler. I’ve joked several times about PHP and ASP support being dropped. Not without good reasons of course but it is what it is.

[Notum]

@George or @patrick May I ask you to comment last reply from @Cheese that in short says - we should not wait for Passport.js feature to be integrated in Wappler at all?

At least 61 community members are waiting for 4 years to have this feature in Wappler.

[Notum]

Bump