Bug? /N/ allows viewing dashboard for account id N for any logged in user, not just members of N

As you would expect, if a user who belongs only to account id 4 tries to view the account details of account id 1 via /accounts/1 the Accounts controller (correctly) rejects that request for that user.

But, unexpected is that a user who belongs only to account #4 enters the url /1 JSP OTB Dashboard controller will allow them to view the Dashboard for that account they are not a member of.

While it is certainly each developers job to check and recheck and write specs re: potential leakage of account info to non-members, it seems to me the OTB Dashboard controller code ought to set a proper example (as does Accounts controller) and restrict viewing of an account's dashboard to members of the account, in the same way and for precisely same reason that a non-logged-in person cannot view any account's dashboard... e.g., the presumption that if you aren't a member of account X you ought not be allowed to see account X's dashboard.

why isn't that the job of the developer to use an authorization scheme where appropriate?   for example, a gem such as pundit or action_policy or others?  Why should JSP enforce authorization which is specific to the particular project's use cases?   

I think what you're seeing is the enforcement of some level of authorization that absolutely cannot be avoided given the rest of the system and which would be common to all projects. And this comes from the notion that project-specific decisions should be made by the developer.  

Do you want JSP to be a Cheetah or a Crocodile?   Every new feature comes with a cost of being potential over-kill, especially when woven so deeply into the system that it cannot easily be yanked out. Therefore every new feature must be essential.   Again, JSP is just a jumping off point.

(Just wait until you need to pull in changes where your project's JSP has diverged from the main branch, oh lawdy are you going to be grateful not to have a whole mess of extras you have to worry might break some of your own code!)

Really, the sooner you think of JSP as not "I'll never need to write code again!" and instead "ok, this shaved about 2 weeks of setup time to get my project off the ground!", the quicker you will get to "oh wait, it's now three months later and JSP is *still* saving me time with good-enough decisions!"

Ew. Ew. Ew. That right there sounds like a knee-jerk apologist rather than a coder actually considering a possible security hole raised. So kindly just skip right over this issue John Quarto-vonTivadar

But to answer the replyer's "why should" - I'll bite, how about because, as I already pointed out, the JSP template handles it everywhere else that I have checked so far. There appears to be one single edge case (so far) that slipped through. And the reply above is what I get back?

Or, if that alone is insufficient, maybe because the front page of the JSP website says: "Authentication / Fully integrated authentication system to keep your app secure".

There is no planet on which (bad) allowing /1 but (good) rejecting /accounts/1 for a non-member is either a) "fully integrated", or b) a reasonable jumping off point. (Unless, I suppose, one feels like "fully integrated" means 'we put some gems in a Gemfile for you')

The issue I raised seems like an inconsistency or oversight. So I reported it. The fact that the Dashboard does get redirected to the index if user not logged-in absolutely, positively, reinforces that the JSP template considers the page is not supposed to be viewed outside of members... but it is in the case described. Fix it, ignore it... up to JSP.

But your post was an unwelcome and condescending* reply to a post about what certainly can be argued to be a (easily remedied) security oversight... a simple "we disagree, we think it's a perfectly reasonable OTB default to give any logged-in user access to any account's dashboard for which they are not a member, caveat fricking emptor" would suffice.

* e.g., your presuming that a 20-years-CTO-silicon-valley (with two IPOs) is somehow naive enough to think "I'll never need to write code again!"

As one of the few trying to point where you can find answers to your 20-year-silicon-valley-veteran-with-exits-because-that's-important beginner questions, all I can say is:   You win, St. Jerome! Thunder on in silence!