I am using an xPage as an iWidget in IBM Connections 3.0.1. I have extended the ajax proxy to point to the nsf. During testing everything was working correctly but I realized it was only working when I was already authenticated with the application (I do use SPENEGO to auth). When I load connections in a fresh browser session I get the BMWIW0001E:Unable to load iWidget error. But if I load the app then reload connections all is well.
Is there a way to pass through the user's credentials or otherwise prompt for a login?
Is there a way to hide the "BMWIW0001E:Unable to load iWidget " error and display a custom error page?
The error message is generated afaik by connections, so you might be better of asking on Server fault or the IBM Connections forum.
For authentication in a mixed environment you have to sort out the trust relationship between the servers. Pick your poison: LTPA, oAuth, not sure about spinego.
As a short term remedy you could use a landing xpage in your widget flagged for anonymous access (allow public access and in the ACL: anonymous with no access but read public access.
In that page you check #UserName and redirect to a mini login or the real widget page. Redirect can be also by loading a dynamic control
Related
Very strange issue I am facing from past few days. I am just able to login to any application on my domino server using "Mozilla Firefox". If I use any other browser (Chrome, IE), it just stays on the login page with absolutely no information, everytime I login in it again shows back the login page with no error message at all. Its quite strange since its working perfectly fine on Firefox.
I am not sure, but I somehow feel that it has something to do with the configuration. Would really appreciate if someone can guide me here.
Edit 2:
Selecting Single Server, does work, that was the simplest solution; as of now we do not need "Multiple Server".
However, we do not use any other "Internet Sites", I tried to remove the organization field, however, that lead me to "An R5 web SSO configuration already exists", which in turn lead me to here. However, I am able to move further here with "Multiple Servers".
Edit 1: Based on the answers, here are the things I tried. Please find below the snapshot of each of it for better understanding..
LTPA Token Configuration
Server Configuration for LTPA Token
Network tab - before login
Network tab - after login
Console shows nothing before or after login, neither does the server log files. Also, I am able to access the names.nsf database with absolutely no problem. Lastly, I try to access a database with no anonymous access and hence get redirected to the login page (however, as question mentions, it just stays in loop)
Ok, you may need to provide a little more information.
Are you doing a "normal" login using domcfg and a "...&login" url? Or are you trying to open a design element in a database that has no access to "anonymous" and thus redirects to the login?
You can easily check that "standard" login by opening the url: http://yourserver.com/names.nsf?login. Does it behave differently in the browsers? If not then your server setup etc. is Ok. Then you have to look at the solution that tries to log you in.
Your first place to check is in the browser's console. Are there any errors in there? E.g. some client side Javascript that stops running? Check the network tab when you inspect the console/developer tools. Does it send the right requests?
Another step is to check the console/log files on the server. If you have grown your own solution then you may want to add some simple print statements to prove that it sends what you think.
Finally, you can use a network sniffer (like wireshark) to see exactly what is sent between your browser and the server.
/John
A login- page that reloads itself after every login without a message like "Wrong username or password" or similar normally happens if the session authentication for the server is configured as Multiple Servers (SSO) (Found in Server document on Internet protocols-Domino Web Server, if Internet Sites are Disabled or in Internet Site document, if they are enabled).
In that case an LTPAToken has to be configured as well, and this token has to have a configured domain name. Whenever you try to access a server with SSO enabled using a hostname without domain or with a different domain, then exactly this will happen: Login- Page reappears after every try to login.
Example:
if the servername is myserver with ip 10.10.10.1 and the LTPAToken is configured for ".mydomain.com", then the only valid URL for login is:
hxxp://myserver.mydomain.com
Trying hxxp://myserver or hxxp://10.10.10.1 will result in exactly the described behaviour.
It is important to know, where to look for the "right" SSO- Configuration document.
If the server is configured to use "Internet Site documents" (Server- document, Basics- Tab, Load Internet configurations from Server\Internet Sites documents enabled) , then the SSO- document needs the field "Organization" to be filled. In that case you will find it in the Web\Internet Sites- View of the domino directory.
If Internet Sites are disabled, then the Field "Organization" has to be empty. In that case you find the SSO- document in the Web\Configurations view.
I've built an XPages with an integrated $$LoginUserForm integrated in the nsf.
Unfortunately my customer doesn't want to make a specific URL for the application (the process to make local DNS entries is apparently too time-consuming to consider).
AFAIK the field 'Web Site/Virtual Server' in the form 'Sign in' Form Mapping is only going to accept either an IP Number or a URL to identify the website, so I'm stuck with using the ugly server-standard form.
Or is there a workaround?
Andrew,
I have played quite a lot with these login forms. And I am afraid that you are right - if you want to use the builtin login redirection method you need to be able to map the login form in domcfg.nsf - either for all sites (which your client may not want) or for specific sites. I have found no way around this. Also it only works with a traditional form with the fields from the standard login form - no WebQuery-agents will run....
But you do have an alternative - if you want to control the login process yourself. Basically, you will need to test if the user is logged in (whereever that is needed) and redirect them to your own login page where you do an AJAX POST to the standard login form and read the credentials - or any login errors - and redirect to the page the user wanted. I do exactly that for an application written in XPages and Java :-)
I have defined an application viewhandler in facesconfig.xml that checks if the user is logged in - and redirects to my login page if login was required and the user had not yet logged in. To rely on Domino's security I have marked all XPages that the user can "reach" from a url as accessibly by anonymous users ($PublicAccess) and then the viewhandler checks for me - and redirects if necessary.
/John
If there is an internet site document available (even with an IP address defined) you should be able to map your login form in the domcfg to that IP/URL and it should be displayed. Did not test it but I think I did this once and it worked.
I have an Internet facing Domino server in our DMZ on which customers log support requests, the customer is required to authenticate, ie. anonymous access is not available. I have developed internal 'wallboards & dashboards' for our support staff, which need to be displayed using web browsers. To allow the wallboard/dashboard web pages to open without authentication I point them at a replica of the database on the second 'internal' server, I do not force a 'consistent access control list' between the replicas and allow Anonymous access to this replica. My problem being that replication across the servers is every 20 mins, so the wallboards are up to 20 minutes behind. I cannot point my wallboard 'Computed Fields' etc at the 'live' database in the DMZ as it throws an error presumably because there is no authentication.
Typical error:
Error while executing JavaScript computed expression
Script interpreter error, line=1, col=57: 'db.getView().getAllEntries()' is null
JavaScript code
1: return db.getView("$FaultStatsDayOpen").getAllEntries().getCount().toFixed();
I imagine I have some of the concepts wrong of how to achieve this. But basically I need XPages from the internal server to be able to retrieve data from views and documents on the DMZ server even though it does not allow Anonymous access.
I can't seem to find this on any of the forums, so any help would be appreciated.
sessionAsSigner allows the code to access databases on any servers in the same domain using the access of the ID signing the XPage. Remember that all design elements included in the XPage need to be signed by the same ID.
If the server is in another domain, you'll need to replicate the database across a server in the same domain in order to access it.
I'm brainstorming a C# project to auto-login to a web portal when a hotkey is pressed. The username and password need to be securely sent to the web portal to login. I have created the hotkey and storage, and retrieval of the credentials, but I'm stuck on how to actually open the default browser and login.
Things I have thought about:
Sending hashed values in the URL (HTTP Get). This is great, because I can just call System.Diagnostics.Process.Start(loginUrl);. But, this creates a LONG URL and run the risk of copy and pasting the URL (I don't want the login URL to be portable or reusable).
Grabbing the COM object and sending into visible forms the creds, then hitting a hidden submit button. All while the current page shows some 'loading' splash. But, this requires grabbing the COM object of an open browser or creating one based on the default browser and hoping that browser compatibility allows me to access the DOM to set the text in the forms and it the submit button. (all hopefully through SSL, although I'm not sure how that will affect things from my end if at all)
I have seen examples on this site using WebRequest and WebResponse. But, do those actually give the commands to the default browser? Or does that make a connection right to the C# program. Becausewhat I really want is to "forward" the credentials to a browser like IE so it can login. Assuming the webpage that I am contacting is HTTPS, then that means I can send unencrypted credentials to the form since they will be secured over the internet? And the end user will not be able to copy the creds since they will be submitted to hidden forms right?
To conclude: I'm looking for a secure way to send credentials to a browser to use to log into a web portal without having to worry too much about browser compatibility.
Thankyou for your time and let me know if I can provide any more information.
Is it possible to secure only the Login.aspx page (and the postback) and not the whole site in IIS?
We are looking to do this specifically with a SharePoint site running Forms Based Authentication against our Active Directory.
Links to this will be helpful.
This is what we have done so far:
1. Setup SharePoint to use FBA against AD.
2. Moved Login Page to Secure/Login.aspx
3. Set the appropriate Login url in web.config as https://..../Secure/Login.aspx
This is not working and help is needed here.
However even if this works, how do we get the user back to http from https?
There's not a whole lot of point. If the only thing that's encrypted is the Login.aspx page, that would mean that someone could sniff all the traffic that was not sent through the login page.
Which might prevent people from getting user:pass, but all your other data is exposed.
Besides all the data which is exposed, and the user's operation which can be changed en route, the user's session id (or other authentication data) is sent in the clear. This means that an attacker can steal your cookie (...) and impersonate you to the system, even without getting your password. (If I remember correctly SPSv.3 also supports builtin password changing module...)
So I would say that this is not a Great Idea, unless you dont care about that system very much anyway.... But then, why bother with authentication at all? just make it anonymous?
I agree with AviD and Dan Williams that securing only the login page isn't a great idea because it exposes other data after leaving the password page. However, you can require SSL for only the login.aspx page via the IIS Manger. If you navigate to the login.aspx page in IIS Manager (I believe it's under /_layouts), you can right-click on the individual file and select Properties. From there, go to the File Security tab and click on the Edit... button under Secure communications. There, you can check the Require secure channel (SSL) box, and SSL will be required for that page only.
I'm not positive about getting the user back to http from there, but I believe its default behavior is to send you to the requested page if the login is successful. If not, I would think you could customize where the login page sends you on a successful login.