Auth tutorial

[jjangga0214]

Feature request

What problem does this feature solve?

In some cases, people would want to use Vuepress for private websites (e.g. private docs for company, half-public-private blog with partially private routing).

Currently, Vuepress does not say anything about Authentication (In contrast to deployment, for example).

On the Internet, I found some people implemented auth behavior directly and solely on Vuepress, without anything else.

For example, I found an article Add Authentication and Personalization to VuePress. This describes how to add auth with Okta.

I saw some other folks use navigation guard on .vuepress/enhanceApp.js(or theme's enhanceApp.js).

export default ({
  Vue, options, router, siteData 
}) => {
  router.beforeEach(async (to, from, next) => {
    // <do some authorization >
  });
};

There's even a plugin like InCuca/vuepress-pass.

However, Vuepress is purely static client-side website, which cannot handle authorization by itself.

So those articles all misunderstood security, or just describe client-side approach which has to combined with server-side setting.

So, in my opinion, it'd be good for official docs to have auth guide.

What does the proposal look like?

Adding some authentication tutorials. Though Vuepress is not responsible for it, it'll be helpful to some people.

For example,

• How to configure popular reverse proxies with Vuepress.
• How to host Vuepress privately on object storage (.e.g AWS S3, Google Cloud Storage), and limit access by serverless function.
• How to handle route-level authorization.
• How to integrate with Auth Providers (e.g. Cognito, Firebase, Auth0, Okta Vue Component)
• How to add a login/logout button on the navigation (e.g. guide to create component and import on navbar, or maybe providing an option out-of-the-box on default theme?).

Are you willing to work on this yourself?

Not sure right now. But I definitly would contribute if possible.

[billyyyyy3320]

Please use issue template.

[jjangga0214]

@newsbielt703 Thanks for prompt response. I updated the issue by template with more context.

[xr0master]

You can see how I did it for my website EmailJS. In short, vuepress is good for a home site. If you need authorization somewhere, then it is better to do it where it is needed. In other words, why do you need authorization on your home site?

[jjangga0214]

@xr0master

In my company, I want to maintain our internal docs by Vuepress. I also want it to be deployed, so accessible by URL, like https://docs.ourcompany.com. However, the docs should be private in our case.

Thus, unauthenticated access to https://docs.ourcompany.com should not be allowed. What's more, authorization policies can be different by routes.

For example, if we use RBAC on routes level, /foo might be only allowed to admin role, while /bar is allowed to admin and employee.

However, even though it requires auth, docs are 100% static. Therefore, I consider Vuepress is still a good choice. That's why I want to implement auth with Vuepress.

How do you think about this conclusion?

[xr0master]

For my company, I did a similar thing through IP restrictions. All go through VPN... Otherwise, it is relatively difficult to do this without your own server, which will give certain permissions to certain users.

[jjangga0214]

@xr0master Well, I think we would not want to rely on VPN. For example, we want to let "temporarily authenticated user"(e.g. by temporary token), who is not our employee or admin, access to our docs. It'd be not suitable to require the user to connect our VPN.

But thanks for the sharing!

[jjangga0214]

By the way, it seems webpack output does not fit with route-based authorization.

Every compiled js files are in a single directory, assets/js. I can't apply route-based reverse proxy policy, for example, because I don't know which files belong to which routes, like /foo or /bar. To know it, one has to read every compiled js files, which is not applicable.

Would it be possible to organize like this?

assets/js
├── index
│   ├── app.0cb5ae60.js 
│   └── 10.059a7fe4.js
├── foo
│   ├── 11.62278c9d.js
│   ├── 12.9652ff3d.js
│   └── 13.c6c6b9fd.js
└── bar
    ├── 14.c8879eeb.js
    ├── 2.99194163.js
    ├── 3.7d54bf6f.js
    ├── 4.0c81bce7.js
    ├── 5.e47d5dbb.js
    ├── 6.004df3e0.js
    ├── 7.966197b8.js
    ├── 8.4bd54fba.js
    └── 9.78a40dc1.js

We might enable a new config option for grouping-components-in-the-same-chunk (webpackChunkName) by routes?

[kissu]

Another way of doing things would be to simply remove SSR from the build and keep it as an SPA (on top of some Auth0 ofc). :smile:

auth0-js and vuepress-auth0 may be useful as packages too. :ok_hand:

[jsonUK]

Been experimenting with static docs like VuePress. So far, best way I have found is to separate "private" docs from public docs, and then adding a htpassword to protect them. Not the best method, but definitely the easiest.

Alternative is investing in paid platforms that have logins and setting private/public pages, but then you are often locked into their ecosystem.

I have seen the same tutorial for Okta - but would be good to have some information that covers building permissions into VuePress at some point - as I believe it definitely is a requirement for a some companies and projects.

[amoschou]

I've been experimenting with publishing to Azure Static Web App and using its built in authentication to manage route based authentication.

An example is available at https://github.com/amoschou/vuepress-azure-swa

This demonstrates a solution that uses Azure's authentication, you might find it meets your needs or can adapt it.

[jjangga0214]

@kissu As I already wrote,

However, Vuepress is purely static client-side website, which cannot handle authorization by itself.

Any pure client-side code cannot handle authorization. Server-side setting is mandatory.

IMHO, packages like vuepress-auth0 can be used with "server" (e.g. reverse proxy), but it does not make sense if configured "alone".

[brunomartinspro]

I have the same issue, I can use programs like broken links checks to crawl all the pages and content before the router.beforeEach. Did anyone fix this issue?