#brofessional_best-practices

1 messages · Page 1 of 1 (latest)

quartz emberBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1238312447111204935

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

quasi surge
#

Hello there, looking...

#

Hmm I am not fully following your question, but Account Session is a backend method and you will need a Secret Key to call it. It's up to you if you open your own endpoint to trigger and retrieve it, but keep in mind it's something should only retrievable within a same security level of a secret key

unkempt burrow
#

Hey @quasi surge - Let me try to clear it up for you. Our WordPress plugin runs on thousands of people's self-hosted websites. I want to display Embedded Connect Components on these websites and securely do so via our Laravel instance, which right now is only handling the oAuth flow and storing values in the local WordPress site and the Laravel's site. I understand the client_secret provided by the Account Session object is sensitive and I don't want any security issues. My question is how can I use these components outside a "Platform" environment and within a "Plugin" one by utilizing the known information from the plugin to our Laravel instance's dbs. Hopefully that helps clear it up and doesn't confuse things more.

#

@proper finch did you get any specific answers in your previous inquiries?

quasi surge
#

Oh the client_secret is exposable in frontend, so it's ok to share

#

I am assuming thousands of people's self-hosted website are all your Connected Accounts? Then you are letting them showing their Dashboard information. The question is who do they show it to? Who are the web viewers?

unkempt burrow
#

@proper finch see above. @quasi surge that's encouraging. I think this is the text within the docs that gives us pause, because we want our solution to be done right and 100% secure:

The client secret can be used to provide access to account from your frontend. It should not be stored, logged, or exposed to anyone other than the connected account. Make sure that you have TLS enabled on any page that includes the client secret.

#

I am assuming thousands of people's self-hosted website are all your Connected Accounts? Then you are letting them showing their Dashboard information. The question is who do they show it to? Who are the web viewers?

#

☝️ yes, that's correct. We are only going to show their dashboard information within WordPress' admin, which is secured by a login and has user-roles. We are not displaying to the public at all. Embedded Connect Components will only display to authenticated admin users. So we will have WP-Admin based authentication first, then role based, then our own authentication.

proper finch
#

Account session generates on Laravel platform on an api endpoint which is protected with strong authentication

quasi surge
#

I see, in that case it’s 👌 to share. But keep in mind you are responsible for the authentication process since e the info is of the Connected Account itself

#

Not sure if it’s possible yet. I would recommend testing in Test mode

#

we might not allow it embeded in an iFrame

#

depends on how WP plug-in is built (sorry not familiar)

unkempt burrow
#

Embedding in iFrame won't work with the modal implementation. It's not a good UX, so we need to use components within the WP plugin.