Admin public index html

AnyConnect Captive Portal Detection and Remediation

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Contents

Introduction

This document describes the Cisco AnyConnect Mobility Client captive portal detection feature and the requirements for it to function correctly. Many wireless hotspots at hotels, restaurants, airports, and other public places use captive portals in order to block user access to the Internet. They redirect HTTP requests to their own websites that require users to enter their credentials or acknowledge terms and conditions of the hotspot host.

Prerequisites

Requirements

Cisco recommends that you have knowledge of the Cisco AnyConnect Secure Mobility Client.

Components Used

The information in this document is based on these software versions:

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Background Information

Many facilities that offer Wi-Fi and wired access, such as airports, coffee shops, and hotels, require users to pay before they obtain access, agree to abide by an acceptable use policy, or both. These facilities use a technique called captive portal in order to prevent applications from connecting until users open a browser and accept the conditions for access.

Captive Portal Remediation Requirements

Support for both captive portal detection and remediation requires one of these licenses:

• AnyConnect Premium (Secure Sockets Layer (SSL) VPN Edition)
• Cisco AnyConnect Secure Mobility

You can use a Cisco AnyConnect Secure Mobility license in order to provide support for captive portal detection and remediation in combination with either an AnyConnect Essentials or an AnyConnect Premium license.

Note: Captive portal detection and remediation is supported on the Microsoft Windows and Macintosh OS X operating systems supported by the release of AnyConnect that is in use.

Captive Portal Hotspot Detection

AnyConnect displays the Unable to contact VPN server message on the GUI if it cannot connect, regardless of the cause. The VPN server specifies the secure gateway. If Always-on is enabled and a captive portal is not present, the client continues to attempt to connect to the VPN and updates the status message accordingly.

If the Always-on VPN is enabled, the connect failure policy is closed, captive portal remediation is disabled, and AnyConnect detects the presence of a captive portal, then the AnyConnect GUI displays this message once per connection and once per reconnect:

The service provider in your current location is restricting access to the Internet. 
The AnyConnect protection settings must be lowered for you to log on with the service 
provider. Your current enterprise security policy does not allow this.

If AnyConnect detects the presence of a captive portal and the AnyConnect configuration differs from that previously described, the AnyConnect GUI displays this message once per connection and once per reconnect:

The service provider in your current location is restricting access to the Internet. 
You need to log on with the service provider before you can establish a VPN session. 
You can try this by visiting any website with your browser.

Caution: Captive portal detection is enabled by default and is nonconfigurable. AnyConnect does not modify any browser configuration settings during captive portal detection.

Captive Portal Hotspot Remediation

Captive portal remediation is the process where you satisfy the requirements of a captive portal hotspot in order to obtain network access.

AnyConnect does not remediate the captive portal; it relies on the end user to perform the remediation.

In order to perform the captive portal remediation, the end user meets the requirements of the hotspot provider. These requirements might include payment of a fee to access the network, a signature on an acceptable use policy, both, or some other requirement that is defined by the provider.

Captive portal remediation must be explicitly allowed in an AnyConnect VPN Client profile if AnyConnect Always-on is enabled and the Connect failure policy is set to Closed. If Always-on is enabled and the Connect Failure policy is set to Open, you do not need to explicitly allow captive portal remediation in an AnyConnect VPN Client profile because the user is not restricted from network access.

False Captive Portal Detection

AnyConnect can falsely assume it is in a captive portal in these situations.

If AnyConnect attempts to contact an ASA with a certificate that contains an incorrect server name (CN), then the AnyConnect client will think it is in a captive portal environment.

In order to prevent this issue, make sure that the ASA certificate is properly configured. The CN value in the certificate must match the name of the ASA server in the VPN client profile.

AnyConnect Behavior

This section describes how the AnyConnect behaves.

AnyConnect tries an HTTPS probe to the Fully Qualified Domain Name (FQDN) defined in the XML profile.

Captive Portal Incorrectly Detected with IKEV2

When you attempt an Internet Key Exchange Version 2 (IKEv2) connection to an ASA with SSL authentication disabled that runs the Adaptive Security Device Manager (ASDM) portal on port 443, the HTTPS probe performed for captive portal detection results in a redirect to the ASDM portal (/admin/public/index.html). Since this is not expected by the client, it looks like a captive portal redirect, and the connection attempt is prevented since it seems that captive portal remediation is required.

Workarounds

If you encounter this issue, here are some workarounds:

Remove HTTP commands on that interface so that the ASA will not listen to HTTP connections on the interface.

This issue is resolved by Cisco bug ID CSCud17825 in Version 3.1(3103).

Caution: The same problem exists for Cisco IOS ® routers. If ip http server is enabled on Cisco IOS, which is required if the same box is used as the PKI Server, AnyConnect falsely detects captive portal. The workaround is to use ip http access-class in order to stop responses to AnyConnect HTTP requests, instead of requesting authentication.

Disable the Captive Portal Feature

It is possible to disable the captive portal feature in AnyConnect client version 4.2.00096 and later (see Cisco bug ID CSCud97386). The administrator can determine if the option should be user configurable or disabled. This option is available under the Preferences (Part 1) section in the profile editor. The administrator can choose Disable Captive Portal Detection or User Controllable as shown in this profile editor snapshot:

If User controllable is checked, the checkbox appears on the Preferences tab of the AnyConnect Secure Mobility Client UI as shown here:

Источник

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

/admin not working. Always shows public/index.html #4271

/admin not working. Always shows public/index.html #4271

Comments

Describe the bug
On http://localhost:1337/admin the Admin Panel should show. But I only see die «Welcome. » Page.

Steps to reproduce the behavior

1. npx create-strapi-app my-project
2. Choose MySQL as Database
3. Insert Credentials
4. Choose «No» for SSL
5. run «strapi start» or «npm run start»

Expected behavior
Admin Panel should show up.

Screenshots

Code snippets
If applicable, add code samples to help explain your problem.

• Node.js version: 10.16.3
• NPM version: 6.12.0
• Strapi version: 3.0.0-beta.17.1
• Database: MySQL
• Operating system: macOS Catalina

The text was updated successfully, but these errors were encountered:

I don’t get it. We need to run development env to get into the CMS?

@cadavre I think you’re expected to use npm run start to run the cms, it doesn’t include the admin pages.

I’m confused now, so /admin isn’t the CMS? 🙂 How can I get to the CMS then? 🙂

There seems to be two parts to this application (please someone correct me if I am wrong).

The first part is the admin interface which is a static website created by npm run build or npm run develop . This output is similar to the built output of a create-react-app application.

The second part is the api which is a node application started by npm run start . This is the rest api between the admin interface and the database.

Ok, so I think we can say /admin is CMS and Strapi itself is a headless-CMS. That’s kind confusing.

The odd part (and my previous question) here is we can manage content via UI by visiting /admin – even if we’re in production – we can manage the content. If we set proper rights we can make user group that will have access to only content edition and not model edition.

But with no /admin we have no content edition. What’s the point of the admin panel then?

The point is that /admin is the GUI where you control the content, models, plugins, and endpoints.

And thanks to Roles & permissions we can give a user access only to Content creator, even in production.

Thanks to @derrickmehaffy for the answer.

Before running strapi().start() in production you need to build the admin interface by running NODE_ENV=production npm run build .

Make sure all strapi processes are killed before running either command.

Edit- this seems to be reflected in the docs but the updates have not made it to strapi.io yet:
https://github.com/strapi/strapi/blob/master/docs/3.0.0-beta.x/guides/deployment.md#deploy-from-github

Okay an explanation of what happen with strapi.

• When you create an application using the quickstart flag — it creates an application with SQLite as database. When the app is created, we automatically run yarn develop . This command checks if there is a built admin — if not — it runs yarn build — then it starts the server.
• When you chose to use a custom database, it will just create the application (the admin is not build — so you can directly access to the admin dashboard)
  So to build the admin you can run yarn develop — that will start your app in dev mode and build your admin if it’s needed.
  You can also run yarn build — it will just run the admin build.
  And the yarn start just launch your server.

So if you create a strapi app with a custom database and you start your server with yarn start the admin has been never built — so no accessible.

Источник