Sponsored Content
Contact Us Post Here to Contact Site Administrators and Moderators Www.UNIX.com is slow today ??? Post 303001331 by Don Cragun on Wednesday 2nd of August 2017 12:28:44 AM
Old 08-02-2017
Quote:
Originally Posted by RavinderSingh13
Thanks a TON Neo for helping here, trust me it is after 2 months I am replying from my own pc(I was working on this site from a friend's Remote pc). I too complained about this few days back in thread Regarding not able to access UNIX.com site

Still I am seeing a very little glitch there, though it is manageable, I would like to request you if we could put some monitoring or etc for this so that we could FIX it if that happens again because I can't LIVE without UNIX.com Smilie

Thank you again for helping here sir.

Thanks,
R. Singh
Hi Ravinder,
What "little glitch" are you seeing?

Cheers,
Don
 

5 More Discussions You Might Find Interesting

1. Post Here to Contact Site Administrators and Moderators

New www.unix.com search

PUZZLED: How can I search for posts on 'VI' if by the new rules (or maybe they are old) I get the messge: "The search term you specified (vi) is under the minimum word length (3) and therefore will not be found. Please make this term longer. If this term contains a wildcard, please make... (13 Replies)
Discussion started by: sierra_aar
13 Replies

2. Post Here to Contact Site Administrators and Moderators

www.unix.com

Of late, when i start www.unix.com my system is going to 100% CPU and takes lot of time to get the information. I think this is happening after adding the graphics on the page. Has anyone seen this problem..Sorry to post this here.. (6 Replies)
Discussion started by: sssow
6 Replies

3. Answers to Frequently Asked Questions

scripts/programs/code posted to www.unix.com

Every now and then our users post complete programs to this site. It is especially important that these contributions don't get lost, so I will collect them here. Some of these programs are intended to demonstrate a programming technique and some are ready to run. As a guideline, the code... (0 Replies)
Discussion started by: Perderabo
0 Replies

4. Forum Support Area for Unregistered Users & Account Problems

Access to https://www.unix.com/source?

Folks, Hope this is not a newbie question, but it might end up being that. I wanted to retrieve the source code for unix_linux_bench as directed on https://www.unix.com/linux-benchmarks/11175-instructions-linux-benchmarks.html When one clicks on the links specified for download, the browser... (1 Reply)
Discussion started by: wagdalule
1 Replies

5. Post Here to Contact Site Administrators and Moderators

Problem connecting to www.unix.com

I've been having a problem connecting to the forum. I know it is just something with my computer but I have no idea what it is. It started last week. Every time I connect I get this: <?xml version="1.0" encoding="ISO-8859-1" ?> - <rss version="2.0"... (2 Replies)
Discussion started by: Vi-Curious
2 Replies
Net::OpenID::ClaimedIdentity(3pm)			User Contributed Perl Documentation			 Net::OpenID::ClaimedIdentity(3pm)

NAME
Net::OpenID::ClaimedIdentity - A not-yet-verified OpenID identity VERSION
version 1.13 SYNOPSIS
use Net::OpenID::Consumer; my $csr = Net::OpenID::Consumer->new; .... my $cident = $csr->claimed_identity("bradfitz.com") or die $csr->err; if ($AJAX_mode) { my $url = $cident->claimed_url; my $openid_server = $cident->identity_server; # ... return JSON with those to user agent (whose request was # XMLHttpRequest, probably) } if ($CLASSIC_mode) { my $check_url = $cident->check_url( delayed_return => 1, return_to => "http://example.com/get-identity.app", trust_root => "http://*.example.com/", ); WebApp::redirect($check_url); } DESCRIPTION
After Net::OpenID::Consumer crawls a user's declared identity URL and finds openid.server link tags in the HTML head, you get this object. It represents an identity that can be verified with OpenID (the link tags are present), but hasn't been actually verified yet. METHODS
$url = $cident->claimed_url The URL, now canonicalized, that the user claims to own. You can't know whether or not they do own it yet until you send them off to the check_url, though. $id_server = $cident->identity_server Returns the identity provider that will assert whether or not this claimed identity is valid, and sign a message saying so. $url = $cident->delegated_url If the claimed URL is using delegation, this returns the delegated identity that will actually be sent to the identity provider. $version = $cident->protocol_version Determines whether this identifier is to be verified by OpenID 1.1 or by OpenID 2.0. Returns 1 or 2 respectively. This will affect the way the "check_url" is constructed. $cident->set_extension_args($ns_uri, $args) If called before you access "check_url", the arguments given in the hashref $args will be added to the request in the given extension namespace. For example, to use the Simple Registration (SREG) extension: $cident->set_extension_args( 'http://openid.net/extensions/sreg/1.1', { required => 'email', optional => 'fullname,nickname', policy_url => 'http://example.com/privacypolicy.html', }, ); Note that when making an OpenID 1.1 request, only the Simple Registration extension is supported. There was no general extension mechanism defined in OpenID 1.1, so SREG (with the namespace URI as in the example above) is supported as a special case. All other extension namespaces will be silently ignored when making a 1.1 request. $url = $cident->check_url( %opts ) Makes the URL that you have to somehow send the user to in order to validate their identity. The options to put in %opts are: "return_to" The URL that the identity provider should redirect the user with either a verified identity signature -or- a setup_needed message (indicating actual interaction with the user is required before an assertion can be made). This URL may contain query parameters, and the identity provider must preserve them. "trust_root" The URL that you want the user to actually see and declare trust for. Your "return_to" URL must be at or below your trust_root. Sending the trust_root is optional, and defaults to your "return_to" value, but it's highly recommended (and prettier for users) to see a simple trust_root. Note that the trust root may contain a wildcard at the beginning of the host, like "http://*.example.com/" "delayed_return" If set to a true value, the check_url returned will indicate to the user's identity provider that it has permission to control the user's user-agent for awhile, giving them real pages (not just redirects) and lets them bounce around the identity provider site for awhile until the requested assertion can be made, and they can finally be redirected back to your return_to URL above. The default value, false, means that the identity provider will immediately return to your return_to URL with either a "yes" or "no" answer. In the "no" case, you'll instead have control of what to do, whether to retry the request with "delayed_return" set true (the only way to proceed in version 2.0) or to somehow send (be it link, redirect, or pop-up window) the user the provider's user_setup_url (which is made available in version 1.0/1.1). When writing a dynamic "AJAX"-style application, you can't use delayed_return because the remote site can't usefully take control of a 1x1 pixel hidden IFRAME, so you'll need to get the user_setup_url and present it to the user somehow. COPYRIGHT, WARRANTY, AUTHOR See Net::OpenID::Consumer for author, copyright and licensing information. SEE ALSO
Net::OpenID::Consumer Net::OpenID::VerifiedIdentity Net::OpenID::Server Website: <http://www.openid.net/> perl v5.14.2 2012-03-18 Net::OpenID::ClaimedIdentity(3pm)
All times are GMT -4. The time now is 01:06 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy