Client portal with security?

I’m trying to build a small school management system within Coda. I will have different docs for admin and faculty. Ultimately, I would like to be able to build a portal for students and parents to be able to check their attendance and grades for each of their classes.

Being on a Pro Teacher account, I don’t have access to doc locking, and the notes on that feature says it isn’t secure because information can be changed via the API.

I’m not sure the best way to set up the student facing portal, a la a client portal. Making students users seems like it would cause issues. It’s important that they not be able to change any information. It would be nice if they could click buttons and select interactive filters for each of their classes, but not be able to find workarounds to edit or show hidden pages.

I’m looking for the most cost effective solution for our small school Any advice?

1 Like

Hey there!

I was a public school teacher for a long time. Now transitioned out and just working on Coda!

What you want is TOTALLY doable and no parents/teachers/ students would even need an account. Heck you don’t even need lock-in! There are ways to set up password protected portals on top of Coda whee unique password actually end up revealing the unique info associated with that password (aka attendance, grades, etc) and only a username/password can access the info.

That being said, it’s quite the complex set up. Before going into detail about how to create it, I’ll let you know the “gotchas”

GOTCHA: anything in a coda doc, no matter how hidden, Can with enough brute force and effort be found and seen despite any in-doc protection measures.

  • Can anyone find it? No not just anyone. With enough measures you can make it extremely difficult to find hidden information inside a doc and one would need to use Codas api or different developer tools to surface information.
  • is this secure enough for me? I use it any many ways for portals with sensitive information. It is technically very secure for many use-cases. That being said, if you are in the states in public Ed you are likely held to FERPA and therefore the mere chance someone might stumble upon grades they shouldn’t see might cross a ferpa line.

the only sure-fire way to hide info is with the use of cross doc. But that’s not going to be a good use case for this. Not scalable. Don’t recommend.

What you COULD do if you are married to using Coda is use a form that acts as a “request” for info, and then trigger automations that then sends the related info to the parents or students via an automated email with the gmail pack. Probably some other fun ways too if I keep thinking about it!

Actually. Give me a moment to ponder. I might have a wild and totally secure solution for you . . .

1 Like

Thanks, this is so helpful!

I’m not married to using Coda for this project. Because of the unique setup of the school as partners of 3 different parent institutions, I can’t accomplish this with a standard LMS and have to get a different tool. We are public, so FERPA is an issue. And the other consideration is keeping costs down.

Out of curiousity, what would be the issue with cross-doc? Just not performant, or some other issue?

Looking forward to hearing more of your thoughts!

Hey @Alan_Patrick_Kenny, welcome to the Community!

The true separation of access is currently only possible through having separate docs (separately shared e.g. one doc per student). Then the data is synced through some sort of a cross-doc mechanism.

There is a default Cross-doc that Coda offers, but it doesn’t scale well with the number of docs — for each student you’d basically have to make a new doc from scratch. Fortunately, I made my own cross-doc implementation, Sync Tables Pro pack designed to solve this problem. See the training videos:

And I recently created a template distribution system that should make it easier to make those doc copies. It’s not yet publicly available (I just built it for a client) but I want to ultimately make it a packaged solution (a doc + a pack).

1 Like

Well. If you want to COMPLETELY separate the information, you’d likely need to do one unique document per student. Which then begs the question - why wouldn’t you just make one document per student to start with?

But that’s a horrible solution. Cross doc was not intended for use cases like this.

Paul’s pack could be a more viable solution. But the again, with this unique solution and Ferpa being involved I would likely do one of two things:

  1. Do the “request” style workflow that emails them the info automatically
  2. Do some other combo of tools like Airtable+softr

Alternatively, if your fine with the 98% secure method of a username and password - you could get it done rather quickly and easily - I would’ve been comfortable with it for my own classroom, but likely not for my whole district.

That makes total sense. If I was to go with the username/password route, what’s the best way to implement that? I haven’t seen it in my googling.

It’s my speciality! I’ve been planning on publishing a YouTube tutorial, it haven’t gotten around to it yet. This might be the kick I need to get it up!

I might be able to have it up by end of next week - alternatively if you need a solution faster email me at and I’ll give you the direction you need.

For what it’s worth, I as the 3rd party pack maker have no access whatsoever to any data that’s being processed through my pack. I can only examine the logs if the person explicitly shares the doc with me.

I could technically leak the data into a doc of my own lol :slight_smile: but of course I’m not doing any of that. If anyone has doubts I can hop on a call and walk the person through the source code (can’t make it open source though because I do want to profit from it; it’s a complicated pack with over 1000 lines of code already just for the cross-doc sync table functionality)

As a person who takes security very seriously, I can’t think of any method that won’t involve cross-doc in this or another way. One idea worth exploring is having not one doc per student but one doc for all students, but it’s separate from your private doc, and there is a cross-doc of all student data flowing into that doc with each student’s data encrypted with a different key. Then students would open that doc in play mode, enter their key, and have their part of the data decrypted but not the other students’ data. Play mode will ensure that the key they enter will not be stored to the doc snapshot and won’t leak to other students.

Another option could be to use something like Looks like a powerful platform though I have not used it much myself…

I’m also very interested in your username/password route…! Any updates pretty please?

@Bas_de_Bruijn , @Scott_Collier-Weir was able to help me and show me what the process would look like. Ultimately the solution isn’t great for my needs and the desire for security.

Instead, I’m going to create docs for each student, now that I found out I can do that formulaically with the Coda Doc List pack.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.